Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
ZiTrAX © (2006-10-15 21:16:00)
Обязательно ли при проектировании БД использовать ограничения ссылочной целостности, master-detail связь? Просто мне удобнее наделать кучу отдельных таблиц, а все связи между ними поддерживать при программировании на Delphi (т.е., если в каком-то поле нужен выбор из другой таблицы, то мне это проще сделать программно). Влияет ли это как-то на скорость работы или на что-то ещё? Или, может, то, что мне удобно, считается дурным стилем или привычкой?

ZiTrAX (2006-10-17 22:10:00) [1]
Спасибо за ссылку! Следующая фраза очень поучительна
> ...закладывать в систему тезис о неизменности ЕК - закладывать
> под себя мину...

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

Zacho (2006-10-17 21:46:00) [3]
ZiTrAX (17.10.06 21:30) [23]
обязательно ли в таблицах использовать автоинкрементные поля

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

saxon (2006-10-17 21:39:00) [4]

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

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

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

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

ZiTrAX (2006-10-17 21:30:00) [5]
Такой вопрос: обязательно ли в таблицах использовать автоинкрементные поля - "идентификаторы" вида *_id, которые однозначно идентифицируют запись? А если первичным ключом сделать VARCHAR размером 60, повлияет ли это как-то на производительность?

Petr V.Abramov (2006-10-17 21:10:00) [6]
> Зато недостаток индексов по внешним ключам может весело приводить к
> блокировке целой подчиненной таблицыв случае изменения/удаления
> записей из главной.
ну тут уж надо выбрать, рыбку или на елку. учитывая, что удаление, вообще говоря, гораздо более редкая операция, чем вставка/обновление, лучше рыбку :)

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

Desdechado (2006-10-17 20:50:00) [7]
Фразу Зато недостаток индексов по внешним ключам можетчитать как Зато отсутствие индексов по внешним ключам может

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

ZiTrAX (2006-10-17 20:07:00) [8]
Спасибо всем, кто откликнулся. Начал переделывать БД, используя ограничения ссылочной целостности, но дело продвигается туговато:-((

Desdechado (2006-10-17 17:49:00) [9]
Вот-вот. Зато недостаток индексов по внешним ключам может весело приводить к блокировке целой подчиненной таблицыв случае изменения/удаления записей из главной. А это прямой путь к дэдлокам.

Sergey13 (2006-10-17 17:01:00) [10]
> [17] Сало (17.10.06 16:47)

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

Сало (2006-10-17 16:47:00) [11]
Радует, что в 2.1 или 3.0 можно будет не создавать индексы по внешним ключам.

Desdechado (2006-10-17 10:38:00) [12]
> делается update индекса - доп. операция
index overhead - не самое страшное в жизни базы

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

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

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

ANB (2006-10-16 15:27:00) [14]

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

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

Sergey13 (2006-10-16 15:20:00) [15]
> И как правило делаю их составными.

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

ANB (2006-10-16 14:46:00) [16]

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

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

Sergey13 (2006-10-16 14:16:00) [17]
> [10] ANB © (16.10.06 14:11)

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

ANB (2006-10-16 14:11:00) [18]

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

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

Sergey13 (2006-10-16 13:38:00) [19]
> [7] ANB © (16.10.06 12:22)

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

Desdechado (2006-10-16 12:50:00) [20]
ANB © (16.10.06 11:47) [4]
> не всегда
Я написал обычно.

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

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

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »