 |
|
Модераторы: LSD |
 
|
|
Юзать или не Юзать составные PrimaryKey? Ваше мнение 
| Romkin |
|
||||||||
|
Бывалый  Профиль Группа: Участник Сообщений: 189 Регистрация: 14.11.2006 Где: Москва Репутация: 1 Всего: 5 |
Возможно. Смотря какая методика репликации. У меня в основной задаче вообще репликацию не сделаешь, не имеет смысла  При перемещении к другому родителю особых проблем не вижу, апдейтятся же первичные ключи подчиненных таблиц, кому какое дело, какое у них значение? И как сделать связь многие-многие без конкатенации первичных ключей связываемых таблиц в таблицу связи? При этом же никого не пугает, что при перемещении он модифицируется...
Почему? Есть же какие-то причины Вообще говоря, первичный ключ - основополагающая единица целостности, а мне выборка с опорой на него нравится своей скоростью...
В какой-то мере - да. Но опять же не вижу особых причин так не делать. Ограничение уникальности должно быть, почему нужно его делать не первичным ключем (при условии, что данные-то не изменятся)? У меня все поля в РК - статичны. Ну почти все ;)
На самом деле, это не так. Я тоже ожидал большого количества полей при проектировании, но, как правило, их 4-5 получается максимально. Да, у меня есть пара таблиц с количеством полей в ключе 6-7, но это, скорее, исключение. Как правило, получается, что связи идут так, что поля сливаются. Разумеется, там, где нужно, я применяю неидентифицирующую связь, но, на мой взгляд, именно там, где надо: у пользователя она отображается в подавляющем большинстве случаев чем-то вроде лукапа. |
||||||||
|
|||||||||
Загрузка ...
| Shaggie |
|
|||
 Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: 1 Всего: 72 |
Почитал... интересно... есть вопрос.
Предположим, существует такая БД:
Логично предположить, что между ними организованиа связь по типу many-to-many. Поэтому создаётся дополнительная таблица "Следователь_Дело", в которой находятся ссылки на первичные ключи двух основных таблиц. Как наиболее эффективно организовать эти ссылки? Создать независимый первичный ключ, а ссылки представить в виде foreign key? Или НЕ СОЗДАВАТЬ отдельный первичный ключ, а реализовать его за счёт композитного ключа этих двух ссылок? --------------------
|
|||
|
||||
| LSD |
|
||||
 Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15718 Регистрация: 24.3.2004 Где: Dublin Репутация: 24 Всего: 538 |
Разве одно дело могут вести два следователя?
Композитный первичный ключ, на основе двух полей. Т.к. в данном случае будет меньше обращений к диску при чтении данных. -------------------- Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it. |
||||
|
|||||
| Shaggie |
|
|||
|
Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: 1 Всего: 72 |
Спасибо, я понял
--------------------
|
|||
|
||||
| Deniz |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1251 Регистрация: 16.10.2004 Где: Новый Уренгой Репутация: 7 Всего: 44 |
LSD,
Могут, не одновременно, в некотором промежутке времени, причем дело может и к первому вернуться, и нужно хранить всю историю. Вот была статья давно, но все же Это сообщение отредактировал(а) Deniz - 21.6.2007, 06:30 -------------------- "Для того чтобы сделать шаг вперед, достаточно пинка сзади" (с) |
|||
|
||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.0494 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |