| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Структура таблиц
Atanas © (2007-03-06 08:35:00)Есть таблица продуктов (Products),со следующими полями:
P_ID (ключевое поле)
P_Name
И подчиненная таблица цен (Prices) на эти продукты, с такими полями:
Pr_ID (ключевое поле)
Pr_P_ID
Pr_Price
Связка между таблицами Pr_P_ID->P_ID
Я часто вижу что в подобных случаях создают ключевое поле (Pr_ID), но вижу смысла в этом поле, ведь связка идет по другим полям, может кто-нибудь объяснить какие преимущества у данного подхода?
Sergey13 (2007-03-06 16:48:00) [1]> [21] Ольга © (06.03.07 16:21)
Замечу лишь одно - сурогатный ПК никак не отменяет естественных ограничений. Никто не мешает создать уникальный индекс по товару+дате.
Ольга (2007-03-06 16:21:00) [2][20]
Преимущества суррогатных ключей вам хорошо описали.
Хочется добавить про недостатки -
искусственный ключ может привести к нарушению естественного (теоретически у вас могут появиться несколько цен за 1 дату), придется наложить уникальный индекс на естественный ключ (цена+дата). Дополнительный индекс, лишнее поле в базе - плата за преимущества суррогатного ключа.
Поэтому в каждом отдельном случае нужно выбирать оптимальный подход, и не в зависимости от предпочтений программиста, а в в зависимости от количества полей естественного ключа, количества внешних связей у таблицы, количества данных в таблице, регламента модификации данных и пр.
В общем, если всего этого много и регламент напряженный - нужен суррогатный ключ, иначе - естественный.
Atanas (2007-03-06 12:01:00) [3]P.S. Если бы я в начале написал что он обязательно нужен, и без него никак, нашлось бы наверное большое количество людей, которые сказали бы, что он здесь нафиг не нужен.
Atanas (2007-03-06 11:56:00) [4]Учиться, учиться и еще раз учиться. (В.И. Ленин)
Актуально млин. Хотел пойти коротким путем, не получилось.
Всем большое спасибо за уделенное время.
Sergey13 (2007-03-06 11:48:00) [5]> [15] Atanas (06.03.07 11:24)
> Опять же какой толк серверу от того что твой "простой сурогатный"
> ключ не учавствует в связке?
Да при чем тут связка? У тебя таблица только для чтения? Ты же в ней пишешь/правишь/удаляешь. Вот для этого и нужен ПК (а вовсе не для связки). Работать с простымПК проще. Но если тебе нравится с двумя полями - флаг в руки - никто не мешает. Место на диске жалко для суррогата что-ли?
sniknik (2007-03-06 11:33:00) [6]> Опять же какой толк серверу от того что твой "простой сурогатный" ключ не учавствует в связке?
> Поправь если ошибаюсь
тебе дали адрес где бушуют баталии "естественный vs сурогатный ключ" уже не первый год... и конца не видно.
а ты хочеш тут простой ответ?... мечтатель. ;)
sniknik (2007-03-06 11:29:00) [7]> В данной конкретной ситуации можно обойтись без Pr_ID (если дату добавить не забудешь)
т.е. в один день не может быть 2х одинаковых цен? (ключ у него насколько понял дата+цена) тогда уж дататайм желательно с миллисекундами потому как если система многопользовательская то и 2 одинаковых цены в секунду тоже вероятны... а милисекунды эту вероятность существенно понизят.
а суррогатный ключ попросту уберет (но это просто, понятно... и неинтересно. интереснее поспорить ;о))
> в том числе и серверу!!!
не волнуйся, счас выяснится, что сервера нет, используется файл серверный принцип, связь работает и без ПК(СК), а для однозначной идентификации записи в тех редких случаях что нужна вполне можно обойтись и номером записи...
;о))
Atanas
это к вопросу о частном случае. твоя "частность" не конкретизирована.
p.s. а интересно, на медицинских форумах, например форуме по лечению гонореи часто возникают вопросы типа "то есть любовь? ... требуется простой, четкий ответ!!!" :))))
Atanas (2007-03-06 11:24:00) [8]Sergey13 © (06.03.07 11:06) [14]
Потому, что это ОБЩЕЕ правило. ПК должен быть.
Тебе кто-то говорил, что ПК не должен быть!? Я предложил пару полей на эту роль. Вместо одного твоего, по которому не построишь (имхо) связку между этими двумя таблицами.
Удобнее и проще (в том числе и серверу!!!) работать с простым сурогатным ПК
Опять же какой толк серверу от того что твой "простой сурогатный" ключ не учавствует в связке?
Поправь если ошибаюсь
Sergey13 (2007-03-06 11:06:00) [9]> [12] Atanas (06.03.07 10:55)
> Господа зачем распространяться от частного к общему?
Потому, что это ОБЩЕЕ правило. ПК должен быть. Удобнее и проще (в том числе и серверу!!!) работать с простым сурогатным ПК.
ЗЫ: Если тебя не устраивают ответы, то может надо правильнее формулировать вопросы?
stone (2007-03-06 11:02:00) [10]
> Atanas (06.03.07 10:55) [12]
В данной конкретной ситуации можно обойтись без Pr_ID (если дату добавить не забудешь). Даже если структура будет меняться, ничто не помешает добавить для связи Pr_ID сделав его автоинкрементным и повесив на него уникальный индекс. Хотя визуально это будет выглядеть не очень, но, как говориться, издержки производства.
Atanas (2007-03-06 10:55:00) [11]Господа зачем распространяться от частного к общему?
Мне всего лишь требовался простой ответ, зачем он нужен, как его можно использовать в данной конкретной ситуации?
Условия можно уточнить: "Структуру менять не будут"
> ЗЫ: Если ты так уверен в своей правоте - нафига спрашивать
> на форуме в тематическом разделе.
Если бы я был уверен, я бы не спрашивал.
Sergey13 (2007-03-06 10:48:00) [12]> [6] Atanas (06.03.07 10:34)
Я тебе предоставил свои доводы против Pr_P_ID+Pr_Date. Может и ты предоставишь свои? Кроме "расплода лишней информации".
> [10] Atanas (06.03.07 10:41)
> Если есть подчиненные, согласен, а если нет?
А если будут? Структуру менять?
ЗЫ: Если ты так уверен в своей правоте - нафига спрашивать на форуме в тематическом разделе. Создай топик в "Потрепаловке" и озаглавь типа "Я открыл новый закон построения БД".
Atanas (2007-03-06 10:41:00) [13]Если у таблицы цен нет подчиненных таблиц
Я это написал в условии.
Если есть подчиненные, согласен, а если нет?
Desdechado (2007-03-06 10:41:00) [14]Чем иронизировать, лучше бы последовал этому универсальному совету.
А вообще холивары "суррогатный vs натуральный первыичный ключ" идут давно, и каждый сам для себя решает. Я предпочитаю однопольный суррогатный. Он легче в поддержании, к нему легко обращаться, он не зависит от случайных переосмыслений предметной области, влияющих на суррогатные ключи.
И место он занимает минимум, так что расплода лишней информацииможешь не бояться.
_Le_ (2007-03-06 10:40:00) [15]А Вы уверены в постоянстве структуры вашей БД ?
Вопросы преимуществ/недостатков сурогатных ключей и естественных можно почитать на sql.ru . Это практически религиозные войны ;)
stone (2007-03-06 10:40:00) [16]
> как можно использовать Pr_ID кроме как для расплода лишней
> информации?
Если есть таблицы, ссылающиеся Prices, то foreign key по одному полю будет более эффективным и экономичным, иначе особого смысла в нем действительно нет.
Atanas (2007-03-06 10:34:00) [17]Поздравляю!!! Ты изобрел универсальный ответ на все вопросы этого и других форумов!!! "Если этот вопрос непонятен, советую почитать литературу"
А если по теме: я считаю что Pr_P_ID+Pr_Date и должен быть первичным ключом. Если у таблицы цен нет подчиненных таблиц, и цена может меняться только раз в день то как можно использовать Pr_ID кроме как для расплода лишней информации?
Sergey13 (2007-03-06 10:22:00) [18]> [4] Atanas (06.03.07 10:18)
Первичны ключ нужен для однозначной идентификации записи в таблице. Это основа основ построения БД. Если этот вопрос непонятен, советую почитать литературу.
Atanas (2007-03-06 10:18:00) [19]
> Pr_ID - это сурогатное ключевое поле для таблицы цен
Перефразирую вопрос для чего сурогатный ключ (Pr_ID), какие преимущества от его использования?
Sergey13 (2007-03-06 09:02:00) [20]> [2] Atanas (06.03.07 08:57)
Так при чем тут связка? Pr_ID - это сурогатное ключевое поле для таблицы цен. В принципе на роль ключа претендует и связка Pr_P_ID+Pr_Date, но она менее стабильна (например дату можно поменять "на пару дней" и после заведения) и более неудобна (чист-канкретна просто больше писать) при ссылках на таблицу цен из других мест.
| |
Страницы: 