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

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

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

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

Че там в акцессе, есть ли подводные камни - не зна .

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

Нет не так. Я против каскадов полностью.

Каскадные обновления - вообще странная операция. В проектируемой вами системе действительно есть процессы, требующие модификации значения PK? Если да, вероятно, что-то не то с дизайном. У меня лишь из пальца высасываются примеры, кода это действительно может быть нужно, и те примеры - не бесспорны.

В Access'е слежки за рекурсивными каскадами нет. Триггеров тоже нет.
Для каждой связи есть только 3 опции:
- обеспечение ссылочной целостности (запрет удаления или изменения, если в связанной таблице есть записи с данным значением FK)
- каскадное обновление
- каскадное удаление


А обеспечение ссылочной целостности - против этого, наверное, не будете ?


У меня - нет, поскольку все PK у меня - числовые идентификаторы.
Но как минимум, в учебных БД ключами могут быть и имена. В этом случае каскадное обновление пригодится.

Это я в курсе. Я не вкурсе не очевидных, глубинных проблем.  


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


Значит вам эта опция не нужна, бритвой Оккамы ее безжалостно отсекем. 


Имена, пожалуй, только в учебных базах и являются ключами.   
На деле, действительно полезным может быть лишь при наличии т.н. натурального(есстественного) ключа.
Но на практике....
Возьмем к примеру товар. У каждого товара есть штрих-код производителя, уникальный в мировом масштабе. Вполне логично бы этот код использовать в качестве естественного ключа. Однако представте стоимость операции модификации такого ключа в мало мальски сложной системе. Если мы попытаемся изменить код товара, нам надо будет изменить все документы, все остатки, все заказы, парайслисты, заявки и мало ли еще чего. На практике эта операция просто не осуществима даже в пределах одной системы. Я уже не говорю о том, что у нас могут быть несколько интегрированных между собой систем, использующих единую систему кодов... ну или взаимодействующих через перекодировку.


Это сообщение отредактировал(а) Zloxa - 29.6.2012, 20:23

Zloxa, как насчёт 2 вариантов реализации связи между таблицей Адрес и таблицей организации/объекта/отдела ?
Какой из двух вариантов связи Вы бы реализовали в случае, когда адрес выделен в отдельную таблицу ?
а) сущности "Организация", "Объект" и "Отдел" имеют поле "id адреса"
б) сущность "Адрес" имеет поля "id организации", "id объекта" и "id отдела"

P.S. Гляньте ещё вот эту тему, если занимаетесь программированием.

Это сообщение отредактировал(а) CyraxZ - 1.7.2012, 22:58

Я перестал улавливать суть идеи, которую вы пытаетесь реализовать, не могу коментировать решения.
Пробуйте.
Если реализуете криво, рано или поздно, поймете в чем накосячили.