Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Firebird, Interbase > Удаление "потерянных" записей в таблицах

Автор: Fortop 13.3.2008, 21:45

Цитата(Akella @  13.3.2008,  09:30 ) чтобы такого бардака не было - нуна использовать ссылочные ограничения, чтобы серер не давал возможности удалять из справочника то, на что ссылается главная таблица  Можно поподробнее про возможности этого механизма? В частности интересует - совершенно противоположная вещь  Реализовано ли автоматическое удаление связанных записей после удаления соответствующего ID в главной таблице или надо все резать вручную? Поясню почему интересуюсь. Поддерживается и переписывается база с сложной структурой (свыше 150 таблиц, 250 триггеров, и 200 хранимых процедур) В таблицах часто остается достаточно много мусора от незавершенных "транзакций" - которые бизнес, не серверные. По разным причинам. Комплекс должен быть рабочим постоянно. Единственное разумное решение к которому пришел - это сборщик мусора, который периодически запускается для чистки структуры данных. Какие у кого есть предложения по этой теме?

Автор: Akella 13.3.2008, 22:36

Цитата(Fortop @  13.3.2008,  21:45 ) Можно поподробнее про возможности этого механизма? о ссылочной целостности? Добавлено через 1 минуту и 7 секунд Цитата(Fortop @  13.3.2008,  21:45 ) Реализовано ли автоматическое удаление связанных записей после удаления соответствующего ID в главной таблице нет, зачем удалять запись из справочника???????????????? тем более, что запись из справочника может быть привязана к другой таблице или к другой записи Добавлено через 2 минуты и 7 секунд но есть такая возможнось   , в IBExpert ты задаёшь параметр ONDELETE Добавлено через 7 минут и 1 секунду Добавлено через 8 минут и 55 секунд Цитата(Fortop @  13.3.2008,  21:45 ) В таблицах часто остается достаточно много мусора от незавершенных "транзакций" что за мусор? делай бэкап/рестор, при бэкапе не используй ключ -g Добавлено через 9 минут и 36 секунд Цитата(Fortop @  13.3.2008,  21:45 ) Единственное разумное решение к которому пришел - это сборщик мусора, который периодически запускается для чистки структуры данных. что за мусор такой структуры данных?

Автор: Fortop 13.3.2008, 23:04

Цитата(Akella @  13.3.2008,  22:36 ) о ссылочной целостности? Да. Ибо не пользовался никогда. Цитата(Akella @  13.3.2008,  22:36 ) нет, зачем удалять запись из справочника???????????????? тем более, что запись из справочника может быть привязана к другой таблице или к другой записи Там все сложнее  это не совсем справочник  Вкратце. Вся система - это складской учет большой сложности. Т.е. таблицы , которые я назвал справочниками. На самом деле очень часто обновляются. Число чистых справочников - небольше 15ти и с ними меньше всего проблем. Цитата(Akella @  13.3.2008,  22:36 ) что за мусор? делай бэкап/рестор, при бэкапе не используй ключ -g Поясню, при совершении 1й единственной бизнес-транзакции добавляются записи в 7-8 таблиц. Причем это не чистая нормализация, там примерно 3 сущности участвуют, из того что я успел разобрать  Возникают ситуации, когда записи добавились в 4 таблицы, а еще в 3 добавились некорректно или недобавились вообще. Так и получаются локации без хранилищ, предметы без упаковок, но в контейнерах, которые в свою очередь лежат неизвестно в локации без хранилища  и т.д. Добавлено через 3 минуты и 22 секунды Вот эти состояния я и называю мусором. Новый код уже пишется, но работает параллельно со старым. Поэтому транзакции (серверные) не всегда спасают. P.S. По-хорошему перепроектировать бы и переписать все это.... Но нельзя :( нужна обратная совместимость и постоянно работающая система. При этом она должна постоянно наращивать возможности...

Автор: Akella 14.3.2008, 09:01

Цитата(Fortop @  13.3.2008,  23:04 ) добавились в 4 таблицы, а еще в 3 добавились некорректно или недобавились вообще. ну и проектирование   Добавлено через 1 минуту и 26 секунд добавлять всё нужно в одной транзакции с проверкой, т.е. если записи добавились не во все таблицы - то откат Добавлено через 12 минут и 20 секунд ссылочнная целостность гарантирует что в главную таблицу, поле ID_spravochnik может попасть только значение из поля ID таблицы spravochnik есть 2 таблицы 1 - справочник (spr1), в которой только 2 поля: ID и NAME 2 - основная (tbl), в которой помимо своих полей, если ещё поле id_spr1 в sp1 такие записи: id - name 1 - маша 2 - коля 3 - петя 8 - саша 46 - дима так вот, в поле id_spr1 (главной таблицы) может быть записано число только из этого ряда: 1, 2, 3, 8 или 46. Но для этого требуется создать в главной таблице "ограничение - внешний ключ". Добавлено через 13 минут и 9 секунд     Ещё ньюанс, если поле id_spr1 допускает null значение, то и это значение может быть записано в поле id_spr1

Автор: Akella 14.3.2008, 09:25

Вот тебе пример, посмотри на таблицы, ограничение в главной таблице и представление. Если в IBExpert`е открыть tbl->ограниения->внешние ключи, то увидишь ссылочную целостность

Автор: Deniz 14.3.2008, 12:16

Цитата(Akella @  14.3.2008,  01:36 ) Цитата(Fortop @  13.3.2008,  21:45 Найти цитируемый пост) Реализовано ли автоматическое удаление связанных записей после удаления соответствующего ID в главной таблице нет, зачем удалять запись из справочника???????????????? тем более, что запись из справочника может быть привязана к другой таблице или к другой записи Почему нет? Да. Что бы не приводить весь синтаксис Alter Table, вот только часть Цитата <col_constraint> = [CONSTRAINT constraint] { UNIQUE | PRIMARY KEY | REFERENCES other_table [(other_col [, other_col …])] [ON DELETE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] [ON UPDATE {NO ACTION|CASCADE|SET DEFAULT|SET NULL}] | CHECK (<search_condition>)} т.е. имеем возможность при удалении/обновлении из главной таблицы, во всех подчиненных таблицах  с записями сделать CASCADE DELETE/ SET DEFAULT / SET NULL, причем поскольку это ограничение создается именно в подчиненной таблице, то для каждой можно настроить свое действие. По поводу удаления из справочника: а кто сказал что только справочники являются "главными" таблицами? Пример не очень корректный, но все же как может помочь каскадное удаление (про обновление молчу, т.к. редактирование первичных ключей весьма специфическое занятие): Есть человек в личном органайзере. У него есть куча разных данных в разных таблицах, начиная от списка телефонов, заканчивая разными встречами и заметками. Если пользователь решил удалить этого человека, то при Cascade delete удалятся все записи во всех таблицах по этому человеку.

Автор: Fortop 14.3.2008, 13:48

Цитата(Akella @  14.3.2008,  09:01 ) ну и проектирование  smile Угу именно    Не завернуто все в транзакции, логика раздергана между хранимыми процедурами и клиентской частью.... тупо. Но сюдя по тому что я вижу, это просто маленький проект вырос... Цитата(Akella @  14.3.2008,  09:01 ) Но для этого требуется создать в главной таблице "ограничение - внешний ключ". Вот за это спасибо  не знал.  А остальное  использовал, не зная как оно называется  Цитата(Deniz @  14.3.2008,  12:16 ) т.е. имеем возможность при удалении/обновлении из главной таблицы, во всех подчиненных таблицах  с записями сделать CASCADE DELETE/ SET DEFAULT / SET NULL, причем поскольку это ограничение создается именно в подчиненной таблице, то для каждой можно настроить свое действие. Спасибо. В текущей задаче мне это, к сожалению, не поможет - эта штука будет жить после меня своей жизнью, как и до меня  Но на будущее такие вещи нужны

Автор: Akella 14.3.2008, 14:52

Цитата(Deniz @  14.3.2008,  12:16 ) как может помочь каскадное удаление у меня есть таблица объектов недвижимости, к которой привязан справочник телефонов, так вот реализовано так, что при удалении объекта недвижимости из главной таблицы - удаляется и запись из таблицы телефонов

Автор: Deniz 14.3.2008, 15:42

Цитата(Akella @  14.3.2008,  17:52 ) у меня есть таблица объектов недвижимости, к которой привязан справочник телефонов, так вот реализовано так, что при удалении объекта недвижимости из главной таблицы - удаляется и запись из таблицы телефонов и как это реализовано, если учитывать пост: Цитата(Akella @  14.3.2008,  01:36 ) Цитата(Fortop @  13.3.2008,  21:45 ) Реализовано ли автоматическое удаление связанных записей после удаления соответствующего ID в главной таблице нет, зачем удалять запись из справочника?????????

Автор: Akella 14.3.2008, 17:29

Добавлено @ 17:30 Поле "внешняя таблица" - это главные таблицы, в которых хранятся объекты недвижимости. Добавлено @ 17:31 но в этом случае, получается так, что здесь PHONES выступает в качестве главной таблицы   Добавлено через 4 минуты и 21 секунду когда удаляю что-то из apart, arenda, mediators или offices, то и из phones удаляется соответсвую щая запись

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)