Можно поподробнее про возможности этого механизма?

В частности интересует - совершенно противоположная вещь 
Реализовано ли автоматическое удаление связанных записей после удаления соответствующего ID в главной таблице или надо все резать вручную?

Поясню почему интересуюсь.

Поддерживается и переписывается база с сложной структурой (свыше 150 таблиц, 250 триггеров, и 200 хранимых процедур)
В таблицах часто остается достаточно много мусора от незавершенных "транзакций" - которые бизнес, не серверные. По разным причинам.
Комплекс должен быть рабочим постоянно.

Единственное разумное решение к которому пришел - это сборщик мусора, который периодически запускается для чистки структуры данных.

Какие у кого есть предложения по этой теме?

о ссылочной целостности?

Добавлено через 1 минуту и 7 секунд

нет, зачем удалять запись из справочника???????????????? тем более, что запись из справочника может быть привязана к другой таблице или к другой записи

Добавлено через 2 минуты и 7 секунд
но есть такая возможнось   , в IBExpert ты задаёшь параметр ONDELETE

Добавлено через 7 минут и 1 секунду


Добавлено через 8 минут и 55 секунд

что за мусор? делай бэкап/рестор, при бэкапе не используй ключ -g

Добавлено через 9 минут и 36 секунд

что за мусор такой структуры данных?

Да. Ибо не пользовался никогда.



Там все сложнее  это не совсем справочник 
Вкратце. Вся система - это складской учет большой сложности.

Т.е. таблицы , которые я назвал справочниками. На самом деле очень часто обновляются. Число чистых справочников - небольше 15ти и с ними меньше всего проблем.



Поясню, при совершении 1й единственной бизнес-транзакции добавляются записи в 7-8 таблиц. Причем это не чистая нормализация, там примерно 3 сущности участвуют, из того что я успел разобрать 

Возникают ситуации, когда записи добавились в 4 таблицы, а еще в 3 добавились некорректно или недобавились вообще.

Так и получаются локации без хранилищ, предметы без упаковок, но в контейнерах, которые в свою очередь лежат неизвестно в локации без хранилища  и т.д.

Добавлено через 3 минуты и 22 секунды
Вот эти состояния я и называю мусором. Новый код уже пишется, но работает параллельно со старым. Поэтому транзакции (серверные) не всегда спасают.

P.S. По-хорошему перепроектировать бы и переписать все это.... Но нельзя :( нужна обратная совместимость и постоянно работающая система. При этом она должна постоянно наращивать возможности...

ну и проектирование  

Добавлено через 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

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

Присоединённый файл ( Кол-во скачиваний: 10 )
 S1.rar 32,24 Kb

Почему нет? Да. Что бы не приводить весь синтаксис Alter Table, вот только часть
т.е. имеем возможность при удалении/обновлении из главной таблицы, во всех подчиненных таблицах  с записями сделать CASCADE DELETE/ SET DEFAULT / SET NULL, причем поскольку это ограничение создается именно в подчиненной таблице, то для каждой можно настроить свое действие.
По поводу удаления из справочника: а кто сказал что только справочники являются "главными" таблицами?
Пример не очень корректный, но все же как может помочь каскадное удаление (про обновление молчу, т.к. редактирование первичных ключей весьма специфическое занятие):
Есть человек в личном органайзере. У него есть куча разных данных в разных таблицах, начиная от списка телефонов, заканчивая разными встречами и заметками. Если пользователь решил удалить этого человека, то при Cascade delete удалятся все записи во всех таблицах по этому человеку.

Угу именно   
Не завернуто все в транзакции, логика раздергана между хранимыми процедурами и клиентской частью.... тупо. Но сюдя по тому что я вижу, это просто маленький проект вырос...


Вот за это спасибо  не знал. 
А остальное  использовал, не зная как оно называется 


Спасибо.

В текущей задаче мне это, к сожалению, не поможет - эта штука будет жить после меня своей жизнью, как и до меня 
Но на будущее такие вещи нужны 

у меня есть таблица объектов недвижимости, к которой привязан справочник телефонов, так вот реализовано так, что при удалении объекта недвижимости из главной таблицы - удаляется и запись из таблицы телефонов

и как это реализовано, если учитывать пост:

Добавлено @ 17:30
Поле "внешняя таблица" - это главные таблицы, в которых хранятся объекты недвижимости.

Добавлено @ 17:31
но в этом случае, получается так, что здесь PHONES выступает в качестве главной таблицы  

Добавлено через 4 минуты и 21 секунду
когда удаляю что-то из apart, arenda, mediators или offices, то и из phones удаляется соответсвую щая запись

Это сообщение отредактировал(а) Akella - 14.3.2008, 17:32