Database design question: True or False?

IA72 · Post by **IA72** » 15 Mar 2004 23:02

katit wrote:
JustMax wrote:А чем собственно отличается проверка RI триггером от проверки constraint - ом? Тот же самый внутренний триггер

Помедленне работает.
Болше возможностей обработки.
Проще Deployment

Проще? С триггерами???? Вы шутите

Дополнительная проблема с ними - легко выходят из-под контроля,
особенно когда программисты криворукие - начинаются цикличные вызовы,
становится невозможно проконтролировать процесс, отладка превращается в некое магическое действие. У слабых натур чешутся ручки отключать их для упрощения некоторых действий, в результате вся RI летит к чертям, причем незаметно для глаза. Я такое видел.

oMoses · Post by **oMoses** » 15 Mar 2004 23:11

Открою секрет: автор этих строк - коллега DBA из Индии. Пытался провести данные реплики во внутренний документ на тему о best practises по дизайну баз даных. В процессе нашей дискуссии (краткой, но емкой) у меня сложилось впечателение, что мысли эти - вообще не его собственые. У них там (в Индии) похоже повсеместно подобные проявления инопланетного интеллекта. Глянешь в офшорный код - и сразу видешь, что логика принадлежит ET - до того все чуждо!

Хоть-бы оговорку сделал на некоторые исключения, что-ли - я бы понял! Короче, вконец уже даже засомневавшись и в собственной нормальности, я и опубликовал выдержки из этого Анупкумара Джейчандрана.

IA72 · Post by **IA72** » 15 Mar 2004 23:12

JustMax wrote:
IA72 wrote: Первые два бред, хотя допускаю случаи, когда приходится жертвовать FK & RI во имя быстродействия (у нас было раз подобное, когда приходилось заливать много данных, но вышли из положения удаляя и восстанавливая индксы и FK после процесса).

Это абсолютно нормальная ситуация - когда точно знаешь, что делаешь. Но как минимум при такой операции TABLE EXCLUSIVE LOCK!

Ну, как, мы тут все круты, понятное дело

Мы просто блокировали главный сервер приложений, который делал load balancing и раскидывал клиентов по серверам с db access, в результате клиент получал сообщение о сервисных работах при попытке зайти в систему.

JustMax wrote:
IA72 wrote: Третий же пункт я обеими руками "за". PK только artificial, со временем жизни равным времени жизни записи. Распространенное исключение - many-2-many таблица, в которой PK - пара ключей из связки.

Спорный вопрос - тут дело вкуса.

Не совсем. Если мне не изменяет память, о неизменности PK говорили большевики, то есть Код в теории реляционных баз

tengiz · Post by **tengiz** » 15 Mar 2004 23:14

Это конечно полный экстрим и имеет смысл только для СУБД, оптимизатор которой не умеет полезно пользоваться наличием декларативных ограничений целостности. Если проблема только в замедлении массовых операций, то для этого существует временное отключение ограничений, при этом хорошо, если сервер умеет правильно пометить ограничения как не заслуживающие доверия, после чего оптимизатор перестанет на них полагаться до момента, когда при включении ограничений будет сделана их проверка.

В общем, реазилация ограничений исключительно на триггерах или хранимых процедурах полностью отрубает массу эффективных техник оптимизации, например при генерации планов с соединениями таблиц. Опять же, если СУБД умеет этим полезно пользоваться. И, разумеется, если менеджер/разработчик вообще в курсе, что такие вещи бывают в природе вообще, и в СУБД на которой ведётся разработка проекта в частности.

Dmitry67 · Post by **Dmitry67** » 15 Mar 2004 23:20

tengiz, не могли бы Вы пояснить
В каких случаях проверка FK будет более эффективна чам sp ?
При испльзовании SP как правило целостнотсь гарантируется 'по построению'
Соответственно поверок вообще не нужно как в примере ниже любой FK буде только тормозом

insert into MasterTable ... <one record>
set @i=@@identity
insert into Details ... @i,other columns

katit · Post by **katit** » 15 Mar 2004 23:25

IA72 wrote: Дополнительная проблема с ними - легко выходят из-под контроля,
особенно когда программисты криворукие - начинаются цикличные вызовы,
становится невозможно проконтролировать процесс, отладка превращается в некое магическое действие. У слабых натур чешутся ручки отключать их для упрощения некоторых действий, в результате вся RI летит к чертям, причем незаметно для глаза. Я такое видел.

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

А насчет всего остального согласен. Но программисты не криворукие :roll:

Так что все вроде работает.
Ну и база сложная. Много чего надо делать в триггерах.

IA72 · Post by **IA72** » 15 Mar 2004 23:34

katit wrote:Проше в смысле установки базы клиенту. Я знаю что есть инструменты и т.п. Но намного проще все таблицы создать, заполнить и создать триггеры (причем порядок создания не имеет значения).

А чем это проще constraints? И потом, если вы создадите таблицы, заполните их данными и потом создадите триггера, у вас некоторым магическим путем получится база с правильным RI? Именно это я и имею ввиду, говоря о потере RI незаметно.

tengiz · Post by **tengiz** » 15 Mar 2004 23:57

Dmitry67,

а я и не говорил, что проверка FK будет всегда эффективнее - в большинстве разумных случаев она будет точно не хуже, в некоторых случаях будет лучше, а в случаях типа того, что Вы привели - да будет хуже. Но это частный случай, когда и master строка и detail строка вставляются в таблицы в одной транзакции.

Но я имел в виду другое - скажем, есть некий сложный запрос, в котором кроме всего прочего есть таблицы, как связанные DRI, так и не связанные, а также имеются внешние соединения. Оптимизатор, рассматривая трансформации исходного запроса может наткнуться на такой вариант - detail LEFT JOIN master. Понятно, что из-за наличия DRI это даст ровно тот же эффект как detail INNER JOIN master. А для INNER JOIN, вообще говоря, можно иметь более эффективный алгоритм. Т.е. оптимизатор имеет большее пространство эквивалентных транформаций, возможно приводящее к лучшим планам.

vc · Post by vc » 16 Mar 2004 00:18

IA72 wrote:
katit wrote:Проше в смысле установки базы клиенту. Я знаю что есть инструменты и т.п. Но намного проще все таблицы создать, заполнить и создать триггеры (причем порядок создания не имеет значения).

А чем это проще constraints? И потом, если вы создадите таблицы, заполните их данными и потом создадите триггера, у вас некоторым магическим путем получится база с правильным RI? Именно это я и имею ввиду, говоря о потере RI незаметно.

This is truly a funny thread. Turns out the majority of people using the database and participating in the discussion are not so far, ideologically speaking, from the author of the database design manifesto (see the firs posting) whom they criticize so harshly.

Why not read, like, a book or something, say, 'Database Design' by Chris Date before making ludicrous statements about how bad RI is in comparison to some n-th Java/SP/trigger based/C# re-implementation du jour of the above ?

Speaking of simplicity, nothing beats flat files in this respect, you know...

Rgds.

JustMax · Post by **JustMax** » 16 Mar 2004 00:47

2 vc
Respect!

JustMax · Post by **JustMax** » 16 Mar 2004 00:55

IA72 wrote: Не совсем. Если мне не изменяет память, о неизменности PK говорили большевики, то есть Код в теории реляционных баз

Я уважаю большевиков

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

IA72 · Post by **IA72** » 16 Mar 2004 01:10

JustMax wrote:
IA72 wrote: Не совсем. Если мне не изменяет память, о неизменности PK говорили большевики, то есть Код в теории реляционных баз

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

Логично. Ни в коем случае не пытаюсь утверждать, что всегда надо делать каким-то единственным правильным методом.
Что касается докладчика выше, так народ пользует джавабины и клиентов для логики не от хорошей жизни. Я горой за DRI и сам перечисленное не употребляю, но каждый раз, когда приходится переключаться из VS.NET или Delphi в Query Analyzer или SQL Navigator, тошнит так что хочется выпить, забить на правильность и писать логику в обьектах, тем более что доступ к базе напрямую у меня и так уже ограничен до минимума.
Это же каменый век, отлаживаться printf, intellicense нет, язык кобольих времен. Где, мля, Юкон наконец? Враги опять перенесли, на 2005.

Victor · Post by **Victor** » 16 Mar 2004 18:17

Это же каменый век, отлаживаться printf

SQL отладчики существуют дочтаточно давно. По крайней мере для SQL Server и Oracle

IA72 · Post by **IA72** » 16 Mar 2004 18:32

Victor wrote:
Это же каменый век, отлаживаться printf
SQL отладчики существуют дочтаточно давно. По крайней мере для SQL Server и Oracle

Разумеется, есть. Но по крайней мере для MS SQL такие, что проще printf.
А для Oracle многие пользуются?

Dmitry67 · Post by **Dmitry67** » 16 Mar 2004 21:47

IA72 wrote:Это же каменый век, отлаживаться printf, intellicense нет, язык кобольих времен. Где, мля, Юкон наконец? Враги опять перенесли, на 2005.

Вот уже блин началось
Пошел миф что в Yukon можно писать порцедуры на c#, SQL можно не знать
Процедуры то писать можно. Какой нибудь перевод текста или обработка изображения, ради Бога
А вот если вместо одного реляционного оператора напишете как это обычно проход в цикле по записям, то никаких чудес в Yukon не будет, как и сейчас, это будет в 100-1000 раз медленнее

Еще боюсь что будут лепить процедуры на C#, и уже не скопируеш базу просто так backup на другой сервер, она будет тянуть DLL, ActiveX И прочую лабуду