Структура таблиц

← →
Atanas (2007-03-06 08:35) [0]

Есть таблица продуктов (Products),со следующими полями:
P_ID (ключевое поле)
P_Name
И подчиненная таблица цен (Prices) на эти продукты, с такими полями:
Pr_ID (ключевое поле)
Pr_P_ID
Pr_Price
Связка между таблицами Pr_P_ID->P_ID

Я часто вижу что в подобных случаях создают ключевое поле (Pr_ID), но вижу смысла в этом поле, ведь связка идет по другим полям, может кто-нибудь объяснить какие преимущества у данного подхода?

← →
Sergey13 © (2007-03-06 08:45) [1]

> ведь связка идет по другим полям

По каким?

Недоработанная структура как минимум (если это вся структура). Ибо позволяет (без путанницы) ввести только одну цену, т.е. связь 1:1.

← →
Atanas (2007-03-06 08:57) [2]

> Sergey13 © (06.03.07 08:45) [1]

> По каким?

Написал же
> Связка между таблицами Pr_P_ID->P_ID

Еще извиняюсь, в ценах есть еще поле Pr_Date (дата, с которой вводится цена)

← →
Sergey13 © (2007-03-06 09:02) [3]

> [2] Atanas (06.03.07 08:57)

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

← →
Atanas (2007-03-06 10:18) [4]

> Pr_ID - это сурогатное ключевое поле для таблицы цен

Перефразирую вопрос для чего сурогатный ключ (Pr_ID), какие преимущества от его использования?

← →
Sergey13 © (2007-03-06 10:22) [5]

> [4] Atanas (06.03.07 10:18)

Первичны ключ нужен для однозначной идентификации записи в таблице. Это основа основ построения БД. Если этот вопрос непонятен, советую почитать литературу.

← →
Atanas (2007-03-06 10:34) [6]

Поздравляю!!! Ты изобрел универсальный ответ на все вопросы этого и других форумов!!! "Если этот вопрос непонятен, советую почитать литературу"
А если по теме: я считаю что Pr_P_ID+Pr_Date и должен быть первичным ключом. Если у таблицы цен нет подчиненных таблиц, и цена может меняться только раз в день то как можно использовать Pr_ID кроме как для расплода лишней информации?

← →
stone © (2007-03-06 10:40) [7]

> как можно использовать Pr_ID кроме как для расплода лишней
> информации?

Если есть таблицы, ссылающиеся Prices, то foreign key по одному полю будет более эффективным и экономичным, иначе особого смысла в нем действительно нет.

← →
_Le_ (2007-03-06 10:40) [8]

А Вы уверены в постоянстве структуры вашей БД ?
Вопросы преимуществ/недостатков сурогатных ключей и естественных можно почитать на sql.ru . Это практически религиозные войны ;)

← →
Desdechado © (2007-03-06 10:41) [9]

Чем иронизировать, лучше бы последовал этому универсальному совету.

А вообще холивары "суррогатный vs натуральный первыичный ключ" идут давно, и каждый сам для себя решает. Я предпочитаю однопольный суррогатный. Он легче в поддержании, к нему легко обращаться, он не зависит от случайных переосмыслений предметной области, влияющих на суррогатные ключи.
И место он занимает минимум, так что расплода лишней информации можешь не бояться.

← →
Atanas (2007-03-06 10:41) [10]

Если у таблицы цен нет подчиненных таблиц
Я это написал в условии.
Если есть подчиненные, согласен, а если нет?

← →
Sergey13 © (2007-03-06 10:48) [11]

> [6] Atanas (06.03.07 10:34)

Я тебе предоставил свои доводы против Pr_P_ID+Pr_Date. Может и ты предоставишь свои? Кроме "расплода лишней информации".

> [10] Atanas (06.03.07 10:41)
> Если есть подчиненные, согласен, а если нет?
А если будут? Структуру менять?

ЗЫ: Если ты так уверен в своей правоте - нафига спрашивать на форуме в тематическом разделе. Создай топик в "Потрепаловке" и озаглавь типа "Я открыл новый закон построения БД".

← →
Atanas (2007-03-06 10:55) [12]

Господа зачем распространяться от частного к общему?
Мне всего лишь требовался простой ответ, зачем он нужен, как его можно использовать в данной конкретной ситуации?
Условия можно уточнить: "Структуру менять не будут"

> ЗЫ: Если ты так уверен в своей правоте - нафига спрашивать
> на форуме в тематическом разделе.

Если бы я был уверен, я бы не спрашивал.

← →
stone © (2007-03-06 11:02) [13]

> Atanas (06.03.07 10:55) [12]

В данной конкретной ситуации можно обойтись без Pr_ID (если дату добавить не забудешь). Даже если структура будет меняться, ничто не помешает добавить для связи Pr_ID сделав его автоинкрементным и повесив на него уникальный индекс. Хотя визуально это будет выглядеть не очень, но, как говориться, издержки производства.

← →
Sergey13 © (2007-03-06 11:06) [14]

> [12] Atanas (06.03.07 10:55)
> Господа зачем распространяться от частного к общему?
Потому, что это ОБЩЕЕ правило. ПК должен быть. Удобнее и проще (в том числе и серверу!!!) работать с простым сурогатным ПК.

ЗЫ: Если тебя не устраивают ответы, то может надо правильнее формулировать вопросы?

← →
Atanas (2007-03-06 11:24) [15]

Sergey13 © (06.03.07 11:06) [14]
Потому, что это ОБЩЕЕ правило. ПК должен быть.
Тебе кто-то говорил, что ПК не должен быть!? Я предложил пару полей на эту роль. Вместо одного твоего, по которому не построишь (имхо) связку между этими двумя таблицами.
Удобнее и проще (в том числе и серверу!!!) работать с простым сурогатным ПК

Опять же какой толк серверу от того что твой "простой сурогатный" ключ не учавствует в связке?

Поправь если ошибаюсь

> В данной конкретной ситуации можно обойтись без Pr_ID (если дату добавить не забудешь)
т.е. в один день не может быть 2х одинаковых цен? (ключ у него насколько понял дата+цена) тогда уж дататайм желательно с миллисекундами потому как если система многопользовательская то и 2 одинаковых цены в секунду тоже вероятны... а милисекунды эту вероятность существенно понизят.
а суррогатный ключ попросту уберет (но это просто, понятно... и неинтересно. интереснее поспорить ;о))

> в том числе и серверу!!!
не волнуйся, счас выяснится, что сервера нет, используется файл серверный принцип, связь работает и без ПК(СК), а для однозначной идентификации записи в тех редких случаях что нужна вполне можно обойтись и номером записи...
;о))

Atanas
это к вопросу о частном случае. твоя "частность" не конкретизирована.

p.s. а интересно, на медицинских форумах, например форуме по лечению гонореи часто возникают вопросы типа "то есть любовь? ... требуется простой, четкий ответ!!!" :))))

> Опять же какой толк серверу от того что твой "простой сурогатный" ключ не учавствует в связке?
> Поправь если ошибаюсь
тебе дали адрес где бушуют баталии "естественный vs сурогатный ключ" уже не первый год... и конца не видно.
а ты хочеш тут простой ответ?... мечтатель. ;)

> [15] Atanas (06.03.07 11:24)
> Опять же какой толк серверу от того что твой "простой сурогатный"
> ключ не учавствует в связке?
Да при чем тут связка? У тебя таблица только для чтения? Ты же в ней пишешь/правишь/удаляешь. Вот для этого и нужен ПК (а вовсе не для связки). Работать с простым ПК проще. Но если тебе нравится с двумя полями - флаг в руки - никто не мешает. Место на диске жалко для суррогата что-ли?

← →
Atanas (2007-03-06 11:56) [19]

Учиться, учиться и еще раз учиться. (В.И. Ленин)
Актуально млин. Хотел пойти коротким путем, не получилось.

Всем большое спасибо за уделенное время.

← →
Atanas (2007-03-06 12:01) [20]

P.S. Если бы я в начале написал что он обязательно нужен, и без него никак, нашлось бы наверное большое количество людей, которые сказали бы, что он здесь нафиг не нужен.

[20]
Преимущества суррогатных ключей вам хорошо описали.
Хочется добавить про недостатки -
искусственный ключ может привести к нарушению естественного (теоретически у вас могут появиться несколько цен за 1 дату), придется наложить уникальный индекс на естественный ключ (цена+дата). Дополнительный индекс, лишнее поле в базе - плата за преимущества суррогатного ключа.
Поэтому в каждом отдельном случае нужно выбирать оптимальный подход, и не в зависимости от предпочтений программиста, а в в зависимости от количества полей естественного ключа, количества внешних связей у таблицы, количества данных в таблице, регламента модификации данных и пр.
В общем, если всего этого много и регламент напряженный - нужен суррогатный ключ, иначе - естественный.

> [21] Ольга © (06.03.07 16:21)

Замечу лишь одно - сурогатный ПК никак не отменяет естественных ограничений. Никто не мешает создать уникальный индекс по товару+дате.

Структура таблиц Найти похожие ветки