|
FOREIGN KEY definition
|
|||
---|---|---|---|
#18+
Народ! Или я не догоняю и это действительно так? ALTER TABLE xxx ADD CONSTRAINT fk_xxx_yyy FOREIGN KEY (field) REFERENCES yyy ... В Oracle продолжение может быть [ON DELETE {CASCADE | SET NULL}], а в Interbase [ON UPDATE {CASCADE | SET NULL}] [ON DELETE {CASCADE | SET NULL}] и если указать ON UPDATE CASCADE, то при изменении ключа в родительской таблице автоматически обновляется поле вторичного ключа в дочерней, что избавляет от необходимости написания триггера AFTER UPDATE для ослеживания изменения ключа в родительской и обновления ключей дочерних таблиц. Неужели Oracle в этом плане уступает InterBase и необходимо писать массу аналогичных триггеров? ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2001, 07:19 |
|
FOREIGN KEY definition
|
|||
---|---|---|---|
#18+
Я тоже этого не нашел. только практика постоянного изменения ключей очевидно не очень удачная. попробуй обойтись каким-нибудь подставным полем, которое никогда не изменяется а все время нарастает и используй его вместо ключа. По большому счету все время лопатить дочерние записи не разумно. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2001, 13:56 |
|
FOREIGN KEY definition
|
|||
---|---|---|---|
#18+
АВТОР. Уточняю. Здесь проблема немного в другом. Из клиентского приложения ключевых полей может быть не видно или они ReadOnly. Давать права на таблицу в целом несколько легче, чем на отдельные поля. Обычно пользователю дается право обновлять либо все поля, либо ни одного. Допустим постепенно пользователи умнеют и начинают сами по-немногу писать запросы на SQL. Выбирают например данные из таблицы с информацией об организациях с которыми работает предприятие и каким-нибудь UPDATE решают изменить код любимой организации, думая что это позволит ей быть первой в списке (для ускорения работы, например). И если в этом случае не будет опеспечена целостность, то в базе начнет развиваться бардак. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.10.2001, 19:07 |
|
FOREIGN KEY definition
|
|||
---|---|---|---|
#18+
to: Docent Не сможет пользователь сделать UPDATE ключевого поля, если на него есть ссылки! Тот-же FOREIGN KEY (который не сделает каскадный UPDATE) помешает поменять значение PRIMARY KEY. И целостность не пострадает. В 99% процентах случаев, каскадный UPDATE вообще не нужен. А в 1% необходим, вследствии неправильно спроектированной структуры БД. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2001, 04:44 |
|
|
start [/forum/topic.php?fid=52&fpage=2852&tid=1993518]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
2ms |
others: | 251ms |
total: | 374ms |
0 / 0 |