Поддержка ссылочной целосности

← →
Term (2004-09-29 12:09) [0]

Как лучше сделать контроль ссылочной целостности
с помошью тригеров или
внешних ключей, почему спрашиваю тут мне сказали что задание RELATIONSHIPS типа не столь надёжно

вот и вкрались сомнения

← →
Johnmen © (2004-09-29 12:12) [1]

>тут мне сказали

Аргументы были или просто трепались ?

← →
Nikolay M. © (2004-09-29 12:16) [2]

> тут мне сказали что задание RELATIONSHIPS типа не столь
> надёжно

Бред какой-то.
Существует мнение, что поддержка триргерами более медленная (по идее так и есть, к сожалению, сам не проверял), но она же и более гибкая. Я лично генерю структуры базы CASE-ами, там все сводится к галочке, чем поддерживать целостность. Зато при необходимости можно дописать текст триггера на более сложную логику удаления + при желании вести логи событий.

← →
АлексейК (2004-09-29 12:33) [3]

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

← →
Johnmen © (2004-09-29 12:35) [4]

>АлексейК (29.09.04 12:33) [3]

А по твоему, как реализованы внешние ключи ?
И ты думаешь, они дополнительно не "нагружают" сервер ?

← →
АлексейК (2004-09-29 13:51) [5]

>Johnmen © (29.09.04 12:35) [4]
Значительно меньше.

← →
Johnmen © (2004-09-29 14:09) [6]

>АлексейК (29.09.04 13:51) [5]

Меньше. Но не значительно, это не разы и даже не десятки процентов...
:)

← →
Sergey13 © (2004-09-29 14:13) [7]

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

← →
sniknik © (2004-09-29 14:19) [8]

> потому что они не пишутся программистом.
;о)) а кем же они пишутся? наверное домохозяйками? ;о))

программистами они и пишутся, не прикладниками только, а теми кто ядро/обработку их писал.

p.s. не удержался ;), в принципе то ясно что хотел сказать.

← →
АлексейК (2004-09-29 14:21) [9]

Johnmen © (29.09.04 14:09) [6]
>АлексейК (29.09.04 13:51) [5]

Меньше. Но не значительно, это не разы и даже не десятки процентов...
:)

Все таки заметно. И потом еще что в триггере напишешь, а то и десятки "разов" могут получится.

← →
den_777 (2004-09-29 14:28) [10]

> Существует мнение, что поддержка триргерами более медленная
> (по идее так и есть, к сожалению, сам не проверял),

Проверял на СУБД INFORMIX, на большой базе при удалении большого числа записей.При времении удалении в 20 минут разница была в пару секунд, что наверняка можно списать на погрешность. Так что время должно быть одинаково так как в "нормальных" СУБД констрейнт это и есть системный триггер. Но как я уже писал у MSSQL совсем не похожая на другие СУБД реализация триггеров, так что для достоверности необходимо просто проэкспериментировать именно на MSSQL2000.

← →
Johnmen © (2004-09-29 14:32) [11]

>АлексейК (29.09.04 14:21) [9]

>Все таки заметно.

А я не замечаю - IB/FB. Но давно уверен, что у MSSQL много смешных проблем...:)

← →
АлексейК (2004-09-29 14:50) [12]

В IB реализация триггеров другая (и на мой взгляд более удачная, с точки зрения программирования). В MSSQL нет триггеров ни after ни before. Триггеры в MS SQL Server срабатывают после обновления и один раз на оператор (а не на каждую обновленную запись). В триггере доступна обновленная таблица и две виртуальных таблицы Inserted и Deleted. Так что для доступа к записи я должен обратится к Inserted или Deleted. Правда в MSSQL2000 появился INSTEAD OF. А вот работа внешних ключей оптимизирована очень неплохо.

← →
KSergey © (2004-09-29 15:48) [13]

> А вот работа внешних ключей оптимизирована очень неплохо.

Применительно к MS SQL основная фраза. И пусть эти интербейзники не выпендриваются ;)) (шутка, если кто не понял)

← →
Johnmen © (2004-09-29 15:53) [14]

>АлексейК (29.09.04 14:50) [12]
>А вот работа внешних ключей оптимизирована очень неплохо.

А с чем ты сравниваешь ? Со смешными триггерами ? Так это сравнение некорректно, т.к. суть разные дела...

>KSergey © (29.09.04 15:48) [13]
>Применительно к MS SQL основная фраза.

А в чем оптимизация ?
Шутку поняли...:)

← →
vuk © (2004-09-29 17:00) [15]

to Johnmen © (29.09.04 14:32) [11]:
>Но давно уверен, что у MSSQL много смешных проблем...:)
На чем уверенность основана, поконкретнее можно?

← →
Johnmen © (2004-09-29 17:18) [16]

>vuk © (29.09.04 17:00) [15]

На личном опыте и опыте окружающих.

← →
KSergey © (2004-09-29 17:36) [17]

> [14] Johnmen © (29.09.04 15:53)
> >KSergey © (29.09.04 15:48) [13]
> >Применительно к MS SQL основная фраза.
> А в чем оптимизация ?

Откуда мне знать? Но работает шустрее. Хотя, корректным и аккуратным тестированием не занимался.

← →
vuk © (2004-09-29 17:45) [18]

to Johnmen © (29.09.04 17:18) [16]:
>На личном опыте и опыте окружающих.
А конкретики так и не будет? Интересно же...

← →
Johnmen © (2004-09-29 17:46) [19]

>KSergey © (29.09.04 17:36) [17]
>Но работает шустрее.

Работает шустрее, чем что ?

← →
Johnmen © (2004-09-29 17:47) [20]

>vuk © (29.09.04 17:45) [18]

Будет, если конкретно поставишь вопрос...:)

← →
vuk © (2004-09-29 17:51) [21]

to Johnmen © (29.09.04 17:47) [20]:
>Будет, если конкретно поставишь вопрос...:)
Ставлю. Где конкретно у MSSQL смешные проблемы, упомянутые в [11]?

← →
Nikolay M. © (2004-09-29 17:55) [22]

> Плюсы констрейнтов - они надежнее, потому что они не пишутся
> программистом.

Лично я за последние 4 года написал максимум десяток тригеров, отвечающих за поддержку СЦ, хотя все базы держались именно на тригерах. Получается, мои тригеры - надежные? :)

← →
Johnmen © (2004-09-29 18:01) [23]

>vuk © (29.09.04 17:51) [21]

Одна из них описана в [12]. А нереализованность триггеров вообще до версии 7 вызывает как минимум недоумение. С улыбкой на лице у сдержанного человека и со смехом у несдержанного.

Ещё ?
:)

← →
vuk © (2004-09-29 18:09) [24]

to Johnmen © (29.09.04 18:01) [23]:
>Одна из них описана в [12].
Это просто другой стиль работы с данными. Тому, кто работал только с IB это несколько непривычно, есть такое дело. Но, тем не менее, не вижу неразрешимых проблем при таком подходе к реализации триггеров. Или я не умею их (проблемы) готовить?

>А нереализованность триггеров вообще до версии 7 вызывает как
>минимум недоумение.
В свое время писал на 6.x. Триггеры там были.

>Ещё ?
Ага. :o)

← →
Johnmen © (2004-09-29 18:27) [25]

>vuk © (29.09.04 18:09) [24]

1. Да дело-то не в этом. Дело в удобном и понятном разрешении проблем. И если в Оракле есть и такие и другие триггеры, то это понятно и осязаемо.

2.
>В свое время писал на 6.x. Триггеры там были.

Здесь, возможно, дело в x.
В своё время писал на 0. Триггеров не было.
Мои бывшие коллеги, писавшие на 5, тоже их не обнаружили...:)

3.
>Ага. :o)

Нереализованность containing. Возражения типа "там это через встроенную ф-ию contains" меня не пробивают.

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

"Каждый кулик..." (c)

← →
vuk © (2004-09-29 18:38) [26]

to Johnmen © (29.09.04 18:27) [25]:
>И если в Оракле есть и такие и другие триггеры, то это понятно
>и осязаемо.
Согласен.

>В своё время писал на 0. Триггеров не было.
Может быть. Я имел дело с 6.5

>Нереализованность containing.
Это часть стандарта SQL?

>А вообще я уже жалею, что дал себя втянуть в бессмысленный
>обмен постами.
Я спросил не из желания защищать MSSQL. Мне действительно интересно. Возможно я не вижу каких-то серьезных проблем. А вдруг мне глаза откроют? :o)

>"Каждый кулик..." (c)
У нас и IB используется в некоторых количествах. Так что про кулика - это малость не по делу. :o)

← →
Fay © (2004-09-29 20:09) [27]

2 Term (29.09.04 12:09)
Если Вы знаете чем отличается constraint от триггера, то вопрос должен быть Вам очевиден. Мне так кажется 8)

2 Johnmen © (29.09.04 18:01) [23]
А ошибки в IB/FB, приводящие к тому, что left join выполняется как inner join, считаются смешными?
>> А я не замечаю - IB/FB.
Имеется ввиду "тормозит одинаково"?

← →
YurikGL © (2004-09-29 20:29) [28]

Всегда реализую СЦ с помощью триггеров.

> Fay © (29.09.04 20:45) [29]

Можно и так :-) Я собственно и связи один ко многим с помощью триггеров всегда делал. ИМХО проще гораздо. Вызываешь свои ексепшены если надо... Да и вообще гибче и удобнее.

>vuk © (29.09.04 18:38) [26]

Просто мне показалось, что обмен мнениями скатывается к http://delphimaster.net/view/15-1096463530/
а это абсолютно бессмысленно...Поэтому "кулик" отменяется :)))
Про серьёзные проблемы не скажу, не сталкивался с ними.

>Fay © (29.09.04 20:09) [27]
>А ошибки в IB/FB, приводящие к тому, что left join выполняется
>как inner join, считаются смешными?

Пожалуйста поподробней. С конкретным примером.

>Имеется ввиду "тормозит одинаково"?

Имеется в виду то, что сказано, дословно, без иносказаний и подразумеваний...

dont`t use triggers to implement features, built-in Oracle database.
(C) Oracle Concepts
Цитата может быть не дословной, и даже ваще не про MSSSQL, но, IMHO, прочтя, имеет смысл задуматься.

2 Johnmen © (29.09.04 23:01) [31]
Мне просто показалось, что имеет место наезд на мою любимую СУБД. Причём со стороны FB, с которым я работаю почти каждый день и люто его ненавижу за тормоза, глюки и "недоношенное" всё ваще.

>> Пожалуйста поподробней. С конкретным примером.
Я не полезу сейчас искать описания багов. Но указанную (во что она выливается) ошибку "исправляют" в каждом релизе.

> Я не полезу сейчас искать описания багов. Но указанную
> (во что она выливается) ошибку "исправляют" в каждом
> релизе.

За 6 лет работы с IB ни разу такую ошибку не видел. Может всё-таки конкретный пример приведешь ?

> Причём со стороны FB, с которым я работаю почти каждый
> день и люто его ненавижу за тормоза, глюки и
> "недоношенное" всё ваще.

У меня - ни тормозов, ни глюков ... Может всё-таки в ручках дело ?

Fay © (30.09.04 04:59) [33] Тормоза? Глюки?! MSSQL-щиков к FB подпускать нельзя :))) И наоборот тоже :)
У меня, например, на тестовой БД Firebird 1.0 делал MSSQL 7 по производительности ;)

Хотя буквально в понедельник влетел в хорошенький баг FB1.5.1... Только никак тестовый случай не сделаю :(

Johnmen © (30.09.04 09:55) [37] Да пытался сделать на днях :((
что-то вроде
for select ns.ID, count(distinct ns.CNT)
from n join ns on n.ID = ns.ID
where n.F_ID = ...
group by ns.id
into :ID, :COUNT_CNT
do suspend;

Причем в хранимой процедуре только... И именно count distinct... И именно с группировкой. И именно join. И read committed...
А баг оченно неприятный: сервер хавает виртуальную память. Именно виртуальную. И не отдает до упора :((
Понятно, через некоторое время она кончается. Со всеми вытекающими
Вот пытаюсь воспроизвести лабораторно

>Romkin © (30.09.04 10:03) [38]

Да, это весьма странно...
Надо, действительно, поэкспериментировать. Напр. джоин сделать неявным (from n, ns where n.ID = ns.ID ...) и/или select n.ID, ... group by n.id

Второе не помогает. Да я уже разомкнул на два, один по ID, другой по count :)

Поддержка ссылочной целосности Найти похожие ветки