Database design question: True or False?

oMoses · Post by **oMoses** » 15 Mar 2004 19:16

Constraints in the physical database are not to be used. The main reason for this is that in a 24/7 environment, they can complicate upgrades and alterations to the database. Any data validations should be handled programmatically instead of leaving the responsibility of data validation on the database.

Referential Integrity should not be implemented in the database. There are a number of advantages to this. Firstly, in a development environment, not having RI implemented means that tables can be dropped and recreated and data loaded and deleted without the overhead of having to get the order of operations correct. In the longer term RI has the effect of slowing up inserts and updates, although the overhead on performance has not yet been quantified.

Primary keys should not have any business meaning and they should only be used to identify each row uniquely in the table.

Ну и как Вам?

katit · Post by **katit** » 15 Mar 2004 19:34

oMoses wrote:Ну и как Вам?

MySQL MUST be used as database. All database access should be limited to plain SELECT, INSERT, UPDATE statements.

No more then 2 tables should be used in a query string. :mrgreen:

vc · Post by vc » 15 Mar 2004 19:42

oMoses wrote:...........................
Primary keys should not have any business meaning and they should only be used to identify each row uniquely in the table.

Ну и как Вам?

I think this is someone trying to be funny, right ?

The last paragraph is not so clear-cut though: you can use surrogates but only when there are no natural identifiers, or there are composite keys which substantially degrade performance and complicate referential integrity.

JustMax · Post by **JustMax** » 15 Mar 2004 19:43

Бред сивой кобылы (даже не IMHO)! :pain1:

Lazy44 · Post by **Lazy44** » 15 Mar 2004 19:45

Я бы согласился, если мы говорим про Data Warehouse и боремся за время. Был опыт, когда 5 часов (разница по времени между Восточным побережьем и Гавайями) не хватало, чтобы залить данные и обработать их (ну очень много их было). Тогда пошли именно по этому пути - дропнули FK constraints, check constraints, чтобы ETL тулза работала побыстрее.

Для всего остального - OLTP, batch processing - это не подходит.

Если рассматривать причины неиспользования FK, check constraints, указанные в цитате,то бред полнейший.

ИМХО

katit · Post by **katit** » 15 Mar 2004 19:55

Lazy44 wrote:Я бы согласился, если мы говорим про Data Warehouse и боремся за время. Был опыт, когда 5 часов (разница по времени между Восточным побережьем и Гавайями) не хватало, чтобы залить данные и обработать их (ну очень много их было). Тогда пошли именно по этому пути - дропнули FK constraints, check constraints, чтобы ETL тулза работала побыстрее.

Ну необязательно так. Если боремся за скорость в инсертах то обычно это пару таблиц. Достаточно временно деактивировать ФК. Или я не прав?

testuser · Post by **testuser** » 15 Mar 2004 20:05

А почему бы и нет. Главное все не отдавать на клиентскую сторону.
Т.е. чтобы клиент чистый SQL мог выполнять только в виде SELECT, а INSERT, UPDATE и DELETE делался с помощью stored procedures.

Мне всегда нравилась простота

Kotkov · Post by **Kotkov** » 15 Mar 2004 20:14

С 3-им пунктом 100% согласен, т.к. всегда есть вероятность, что бизнес-логика изменится и начальная уникальность перестанет быть уникальностью.

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

Ну если логика энфорсится в stored procedure То дублировать проверки в FK избыточно
Я меня был опыт очень большого проекта с порядка 500 тали и около 14000 stored proc, гденет ни одного FK
Вся логика в процедурах
Однако вообще от утверждения веет такой категоричностью что работать под этим менеджером я бы не хотел

katit · Post by **katit** » 15 Mar 2004 20:26

Я работаю с базой (1500 таблиц и 2500 процедур) на SQL Server Там все RI сделано через триггеры.
Довольно удобно работать если честно.

IA72 · Post by **IA72** » 15 Mar 2004 20:44

JustMax wrote:Бред сивой кобылы (даже не IMHO)!

Первые два бред, хотя допускаю случаи, когда приходится жертвовать FK & RI во имя быстродействия (у нас было раз подобное, когда приходилось заливать много данных, но вышли из положения удаляя и восстанавливая индксы и FK после процесса).
Третий же пункт я обеими руками "за". PK только artificial, со временем жизни равным времени жизни записи. Распространенное исключение - many-2-many таблица, в которой PK - пара ключей из связки.

JustMax · Post by **JustMax** » 15 Mar 2004 22:27

katit wrote:Я работаю с базой (1500 таблиц и 2500 процедур) на SQL Server Там все RI сделано через триггеры.
Довольно удобно работать если честно.

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

JustMax · Post by **JustMax** » 15 Mar 2004 22:33

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

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

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

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

katit · Post by **katit** » 15 Mar 2004 22:40

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

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

Dmitry67 · Post by **Dmitry67** » 15 Mar 2004 22:47

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

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

Вы наверное про FK без индекса ?
Но тут же по то что времено убирается то и то

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!

Привет

Database design question: True or False?

Database design question: True or False?

Re: Database design question: True or False?

Re: Database design question: True or False?