Master-Detail связь: программно или при проектировании?

← →
ZiTrAX (2006-10-15 21:16) [0]

Обязательно ли при проектировании БД использовать ограничения ссылочной целостности, master-detail связь? Просто мне удобнее наделать кучу отдельных таблиц, а все связи между ними поддерживать при программировании на Delphi (т.е., если в каком-то поле нужен выбор из другой таблицы, то мне это проще сделать программно). Влияет ли это как-то на скорость работы или на что-то ещё? Или, может, то, что мне удобно, считается дурным стилем или привычкой?

← →
Zacho © (2006-10-15 21:42) [1]

То, что тебе удобно, рано или поздно приводит к нарушению ссылочной целостности (Referential Integrity, RI).
Единственный способ гарантированного соблюдения RI - внешние ключи (Foreign Keys, FK)

В некоторых (довольно редких) случаях ради производительности можно пожертвовать FK, но тогда необходимо принимать дополнительные меры для контроля, и в случае нарушения - для восстановления RI.

А вообще для понимания того, что такое RI и зачем она нужна очень рекомендую почитать что-нибудь по теории РСУБД, например К.Дж.Дейт "Введение в системы баз данных"

← →
Desdechado © (2006-10-15 23:01) [2]

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

← →
Deniz © (2006-10-16 07:09) [3]

> Desdechado © (15.10.06 23:01) [2]
>
> при создании внешних ключей обычно автоматом создаются индексыпо этим полям, чтоочень положительно сказывается на скорости доступа к данным

Иногда индексы по FK мешают.

> ZiTrAX (15.10.06 21:16)
Никто не мешает "...все связи между ними поддерживать при программировании на Delphi " при наличие ссылочной целостности, просто в некотрых случаях очень помогает напримет cascade delete.

← →
ANB © (2006-10-16 11:47) [4]

> при создании внешних ключей обычно автоматом создаются индексыпо
> этим полям

не всегда. во всяком случае, в оракле при create constraint индексы автоматом не создаются.

> Иногда индексы по FK мешают.

Это когда ?

← →
Zacho © (2006-10-16 12:01) [5]

ANB © (16.10.06 11:47) [4]
Это когда ?

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

← →
Sergey13 © (2006-10-16 12:08) [6]

> Это когда ?

ИМХО, когда ссылка идет на маленький и стабильный справочник, типа "единиц измерения" или "валюта платежа"

← →
ANB © (2006-10-16 12:22) [7]

> ИМХО, когда ссылка идет на маленький и стабильный справочник,
> типа "единиц измерения" или "валюта платежа"

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

← →
Desdechado © (2006-10-16 12:50) [8]

ANB © (16.10.06 11:47) [4]
> не всегда
Я написал обычно.

> в оракле при create constraint индексы автоматом не создаются
У автора FireBird. Там - создаются.

Deniz © (16.10.06 07:09) [3]
> Иногда индексы по FK мешают.
Знаю только один случай, когда они не то, чтобы мешают, а только поедают дополнительное место. Это случай, когда поле по FK входит частично или полностью в первичный или уникальный ключ. Тогда индекс по FK не нужен, т.к. работает индекс другого ключа. Но это меня не напрягает.
А ты какие "мешалки" знаешь?

> Никто не мешает "...все связи между ними поддерживать при
> программировании на Delphi " при наличие ссылочной целостности
Глупости это. При доступе в БД минуя твою программу в БД образуется невыразимый бардак, который разгрести просто невозможно. И, поверь, если есть возможность такого доступа, ею воспользуются. Такова жизнь.

> просто в некотрых случаях очень помогает напримет cascade delete.
Весьма редко нужное свойство.

← →
Sergey13 © (2006-10-16 13:38) [9]

> [7] ANB © (16.10.06 12:22)

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

← →
ANB © (2006-10-16 14:11) [10]

> тем же ораклом никогда не подхватится

Эт смотря какой запрос. И входит ли этот ID в какой нибудь полезный составной индекс.

← →
Sergey13 © (2006-10-16 14:16) [11]

> [10] ANB © (16.10.06 14:11)

Если он входит в какой то составной индекс, то это как-то не совсем подходит под индекс для констрейнта, согласись.
Т.е. не то что бы совсем никак, но и как обычно. 8-)

← →
ANB © (2006-10-16 14:46) [12]

>
> Sergey13 © (16.10.06 14:16) [11]

Да я индексы по жизни руками создаю. Клипперовая привычка. И как правило делаю их составными.

← →
Sergey13 © (2006-10-16 15:20) [13]

> И как правило делаю их составными.

По какому принципу?

← →
ANB © (2006-10-16 15:27) [14]

> Sergey13 © (16.10.06 15:20) [13]
> > И как правило делаю их составными.
>
> По какому принципу?

Да как больше понравится. :)
Ладно, завязываем.

← →
Deniz © (2006-10-17 09:13) [15]

> Desdechado © (16.10.06 12:50) [8]
> А ты какие "мешалки" знаешь?
В принципе уже ответили, но чуть добавлю.
При изменении(insert, update, delete) таблицы, делается update индекса - доп. операция.

> Глупости это. При доступе в БД минуя твою программу
Имелось ввиду, что ограничения ссылочной целостности не мешают программированию в Delphi, и там можно реализовывать что хочешь.
Или я не так сказал, или ты не так понял, или одно из пяти ;-)
> Весьма редко нужное свойство.
Я же написал "... некотрых случаях ...".

PS:Ладно завязываем. Тем более автора не видать.

← →
Desdechado © (2006-10-17 10:38) [16]

> делается update индекса - доп. операция
index overhead - не самое страшное в жизни базы

← →
Сало (2006-10-17 16:47) [17]

Радует, что в 2.1 или 3.0 можно будет не создавать индексы по внешним ключам.

← →
Sergey13 © (2006-10-17 17:01) [18]

> [17] Сало (17.10.06 16:47)

Это так давит на тебя? 8-)
Эти индексы не всегда приносят ощутимую пользу (достаточно редко, надо заметить), но зато и никогда не наносят ощутимого вреда.

← →
Desdechado © (2006-10-17 17:49) [19]

Вот-вот. Зато недостаток индексов по внешним ключам может весело приводить к блокировке целой подчиненной таблицыв случае изменения/удаления записей из главной. А это прямой путь к дэдлокам.

← →
ZiTrAX (2006-10-17 20:07) [20]

Спасибо всем, кто откликнулся. Начал переделывать БД, используя ограничения ссылочной целостности, но дело продвигается туговато:-((

Фразу Зато недостаток индексов по внешним ключам может читать как Зато отсутствие индексов по внешним ключам может

ZiTrAX (17.10.06 20:07) [20]
> дело продвигается туговато
Ничего. Тяжело в начале, потом зато на автопилоте будешь делать. Заодно, похоже, и структуру к 3-й нормальной форме привести можно.

← →
Petr V.Abramov (2006-10-17 21:10) [22]

> Зато недостаток индексов по внешним ключам может весело приводить к
> блокировке целой подчиненной таблицыв случае изменения/удаления
> записей из главной.
ну тут уж надо выбрать, рыбку или на елку. учитывая, что удаление, вообще говоря, гораздо более редкая операция, чем вставка/обновление, лучше рыбку :)

сами по себе references и check - последний эшелон защиты от развала данных. Если заглючили все проверки на клиенте/в хранимках, юзер получит непонятное ему сообщение, будет недоволен, но данные останутся в целкости и непротиворечивости

← →
ZiTrAX (2006-10-17 21:30) [23]

Такой вопрос: обязательно ли в таблицах использовать автоинкрементные поля - "идентификаторы" вида *_id, которые однозначно идентифицируют запись? А если первичным ключом сделать VARCHAR размером 60, повлияет ли это как-то на производительность?

← →
saxon (2006-10-17 21:39) [24]

> обязательно ли в таблицах использовать автоинкрементные
> поля - "идентификаторы" вида *_id, которые однозначно идентифицируют запись?

Нет, не обязательно.

> А если первичным ключом сделать VARCHAR размером 60, повлияет
> ли это как-то на производительность?

На производительность не повлияет, по крайней мере - ощутимо.
Все зависит, естественно, от задачи, однако, в большинстве случаев так делать не стоит. Лучьше по первому варианту.

ZiTrAX (17.10.06 21:30) [23]
обязательно ли в таблицах использовать автоинкрементные поля

Прочитай http://www.ibase.ru/devinfo/NaturalKeysVersusAtrificialKeysByTentser.html

← →
Petr V.Abramov (2006-10-17 22:08) [26]

> ZiTrAX (17.10.06 21:30) [23]
вот этот вопрос, хоть и серьезный технический, в потрепаловке обычно висит подолгу
P.S. а мое мнение - формально необязательно, но так же необязательно, как чистить зубы :)

← →
ZiTrAX (2006-10-17 22:10) [27]

Спасибо за ссылку! Следующая фраза очень поучительна
> ...закладывать в систему тезис о неизменности ЕК - закладывать
> под себя мину...

Master-Detail связь: программно или при проектировании? Найти похожие ветки