Первичный ключ

← →
Lamer@fools.ua © (2006-04-18 11:07) [200]

>У естественных ключей преимущество в первую очередь в простоте программирования, а как ты сам понимаешь, чем проще программировать, тем меньше ошибок и тем легче сопровождать систему.

IMHO, очень спорное утверждение. Почему, когда я пишу JOIN в запросе, я должен вспоминать, по какому полю (или, упаси Аллах, полям) мне нужно соединять таблицы в ON?

← →
Игорь Шевченко © (2006-04-18 11:10) [201]

vuk © (18.04.06 11:07) [199]

А скажи мне пожалуйста, зачем производители СУБД допускаю.т возможность задания составных ключей ? Чтобы бедным программистам и пользователям мозги засорить ?

Ну вот интересно мне :)

← →
Sergey13 © (2006-04-18 11:14) [202]

2 [201] Игорь Шевченко © (18.04.06 11:10)
>зачем производители СУБД допускаю.т возможность задания составных ключей ?
Они просто оставляют свободу выбора разработчику. Только и всего. А ты думаешь они их этим пропагандируют?

← →
Игорь Шевченко © (2006-04-18 11:26) [203]

Sergey13 © (18.04.06 11:14) [202]

> Они просто оставляют свободу выбора разработчику. Только
> и всего. А ты думаешь они их этим пропагандируют?

Нет, я далек от мысли о какой-либо пропаганде. Я полагаю, что разработчики СУБД допускают использование как естественных, так и искусственных ключей, только и всего. И принимать за догму один из этих вариантов и следовать только ему, по меньшей мере недальновидно.

← →
vuk © (2006-04-18 11:26) [204]

to Игорь Шевченко © (18.04.06 11:10) [201]:
>А скажи мне пожалуйста, зачем производители СУБД допускаю.т
>возможность задания составных ключей ?
Ну ты ж понимаешь. Им надо стричь бабки с приверженцев обеих религий.:o)

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

← →
euru © (2006-04-18 11:27) [205]

> Lamer@fools.ua © (17.04.06 20:42) [184]
>
> К тому же, судя по слову "проводка" речь идёт о бухгалтерской
> системе? Если да, то ещё вопрос: а если документ ещё не
> проведен, а только пока что сохранён?

1. При создании любого бухгалтерского документа (в нашей системе) делается проводка. Так что сохранённых, но непроведённых бухгалтерских документов нет.
2. Однако создавать документы без даты проводки можно. Но эти документы считаются временными и не участвуют в бух. учёте, пока в них не будет указана дата проводки.

> Внук © (17.04.06 20:42) [185]
>
> Каким образом вид ключа влияет на количество операторов
> JOIN? Правда, не понимаю. Суррогатный ключ, состоящий из
> одного поля, наоборот упрощает связи. А вот связывать таблицы
> по информационным полям... Брр.

В бухгалтерии есть операция "сторно" -- отмена проведённого документа другим документом. Соответственно, "сторнированный документ" -- это документ, проводка которого отменяется; "сторнирующий документ" -- документ, отменяющий проводку другого документа.

В случае если один документ (сторнирующий) сторнирует другой (сторнируемый), в записи сторнирующего документа сохранится информация о сторнируемом им документе: интересующий нас ключ.

Допустим, нам нужно найти документ, сторнирующий заданный нами документ.

Случай 1. У нас суррогатный ключ. Сначала по заданным номеру и дате документа находим его ключ. После этого уже ищем документ, в поле "документ сторно" которого записан этот ключ. Если эти действия делать одним оператором SELECT, без JOIN не обойтись.

Случай 2. У нас естественный ключ, состоящий из номера и даты проводки. Сразу ищем документ, в полях которого "номер документа сторно" и "дата проводки документа сторно" записаны номер и дата проводки искомого документа. Обошлись без JOIN.

← →
Sergey13 © (2006-04-18 11:31) [206]

2[203] Игорь Шевченко © (18.04.06 11:26)
> Я полагаю, что разработчики СУБД допускают использование как естественных, так и искусственных ключей, только и всего.
А я полагаю, что им этот вопрос пофиг. 8-)
С точки зрения физического хранения и обработки СК и ЕК (за что и "отвечают" производители СУБД) нет никакой разницы. Разница в наполнеии структуры смыслом - т.е. епархия программиста прикладника.

← →
Игорь Шевченко © (2006-04-18 11:31) [207]

Рекомендую ознакомиться с еще одной точкой зрения -

http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf

vuk © (18.04.06 11:26) [204]

Всякий овощ хорош :) Если его правильно есть :)

← →
Игорь Шевченко © (2006-04-18 11:33) [208]

Sergey13 © (18.04.06 11:31) [206]

> С точки зрения физического хранения и обработки СК и ЕК
> (за что и "отвечают" производители СУБД) нет никакой разницы.
> Разница в наполнеии структуры смыслом - т.е. епархия программиста
> прикладника.

"Страшно далеки они от народа" (с) :)

← →
Sergey13 © (2006-04-18 11:38) [209]

2[208] Игорь Шевченко © (18.04.06 11:33)
> "Страшно далеки они от народа" (с) :)
Более того. Любая СУБД позволяет работать вообще без ключей. 8-)

← →
euru © (2006-04-18 11:39) [210]

> xayam © (17.04.06 23:59) [187]
>
> > euru © (17.04.06 17:42) [179]
>
> Вопрос был не в том испытывает она проблемы по жизни или
> нет, вопрос в способности системы (базы данных) к адаптации
> к изменениям в реальной жизни (ИНН, ISO... ... ...). Если
> Вы используете Естеств.Ключ могу Вас поздравить - гемороя
> не оберетесь (еще раз повторю [30]: а оно Вам надо?), при
> наличии же Сур.Ключа эти изменения сведены к минимуму.

Что Вы говорите? Знали бы разработчики SAP R/3 про геморрой, наверно, несколько раз подумали бы, прежде чем вводить в свою систему естественные ключи.

← →
vuk © (2006-04-18 11:43) [211]

to euru © (18.04.06 11:27) [205]:
Решительно не понимаю, чем извлечение СК из записи отличается от извлечения ЕК из записи кроме как количеством извлекаемых полей.

>Случай 1. У нас суррогатный ключ. Сначала по заданным номеру и дате
>документа находим его ключ.
Вот тут ошибочка. При использовании СК документ будем искать не по номеру и дате, а по СК.

← →
Jeer © (2006-04-18 11:48) [212]

Игорь Шевченко © (18.04.06 11:31) [207]

http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf

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

← →
Jeer © (2006-04-18 11:52) [213]

vuk © (18.04.06 11:43) [211]

> будем искать не по номеру и дате, а по СК.

Причем быстрее, в общем случае.

← →
Игорь Шевченко © (2006-04-18 11:56) [214]

Jeer © (18.04.06 11:48) [212]

> а далее - опыт разработки и сопровождения делает выбор в
> пользу СК.

Чей опыт ?

← →
euru © (2006-04-18 12:15) [215]

> vuk © (18.04.06 11:43) [211]
>
> >Случай 1. У нас суррогатный ключ. Сначала по заданным номеру
> и дате
> >документа находим его ключ.
> Вот тут ошибочка. При использовании СК документ будем искать
> не по номеру и дате, а по СК.

Упс. А откуда пользователь знает суррогатный ключ?

← →
vuk © (2006-04-18 12:24) [216]

to euru © (18.04.06 12:15) [215]:
>Упс. А откуда пользователь знает суррогатный ключ?
Я не понял, Вы собираетесь заставлять пользователя дату с номером руками вбивать?

← →
Суслик © (2006-04-18 12:24) [217]

2vuk

> Я не понял, Вы собираетесь заставлять пользователя дату
> с номером руками вбивать?

Полагаю, что либо руками, либо выбирать из списка (у нас так)

← →
Jeer © (2006-04-18 12:26) [218]

Игорь Шевченко © (18.04.06 11:56) [214]

Личный и коллег.

← →
Anatoly Podgoretsky © (2006-04-18 12:36) [219]

Jeer © (18.04.06 12:26) [218]
Программисты они особые

← →
vuk © (2006-04-18 12:41) [220]

to Суслик © (18.04.06 12:24) [217]:
>Полагаю, что либо руками, либо выбирать из списка (у нас так)
Ага. Это две разных по сути вещи. Если из списка, то кто никто не мешает иметь СК про который пользователь вообще ничего не знает. А если ручной ввод, так там еще и дополнительные проверки на предмет нелевизны введенных данных нужны будут в любом случае. Так что просто выбрать по условию не получится.

← →
Игорь Шевченко © (2006-04-18 12:41) [221]

Jeer © (18.04.06 12:26) [218]

Личный опыт, он есть у каждого. Например, мой опыт говорит мне, что ничего страшного в естественных ключах нету. Опыт конечно аргумент хороший, но он у каждого свой :)

← →
Jeer © (2006-04-18 12:43) [222]

Игорь Шевченко © (18.04.06 12:41) [221]

Есть еще общая практика, основанная на личном опыте каждого.
Она здесь наблюдаема.

← →
Игорь Шевченко © (2006-04-18 12:44) [223]

Jeer © (18.04.06 12:43) [222]

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

← →
Jeer © (2006-04-18 12:47) [224]

Игорь Шевченко © (18.04.06 12:44) [223]

Для задач СУБД это не принципиальный момент - прикладное содержание.

← →
Игорь Шевченко © (2006-04-18 12:51) [225]

Jeer © (18.04.06 12:47) [224]

> Для задач СУБД это не принципиальный момент - прикладное
> содержание.

Весьма спорный тезис.

← →
DiamondShark © (2006-04-18 13:08) [226]

А по-моему, по-барабану какой ключ -- естественный или суррогатный.
Лишь бы его значения были атомарными и компактными.

← →
euru © (2006-04-18 13:47) [227]

> vuk © (18.04.06 12:24) [216]
>
> to euru © (18.04.06 12:15) [215]:
> >Упс. А откуда пользователь знает суррогатный ключ?
> Я не понял, Вы собираетесь заставлять пользователя дату
> с номером руками вбивать?

А Вы, я так понимаю, вместо номера и даты документа предлагаете ему какой-то код вводить.

> vuk © (18.04.06 12:41) [220]
>
> to Суслик © (18.04.06 12:24) [217]:
> >Полагаю, что либо руками, либо выбирать из списка (у нас
> так)
> Ага. Это две разных по сути вещи. Если из списка, то кто
> никто не мешает иметь СК про который пользователь вообще
> ничего не знает. А если ручной ввод, так там еще и дополнительные
> проверки на предмет нелевизны введенных данных нужны будут
> в любом случае. Так что просто выбрать по условию не получится.

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

← →
Внук © (2006-04-18 14:51) [228]

>>euru © (18.04.06 13:47)
Понятно, спасибо за пример. Но в данном случае JOIN ничего не стОит базе данных, поскольку идет обрашение к одной записи из связанной таблицы по значению ПК - практически мгновенно.
Я все читаю примеры, где первичный ключ может использоваться, но не вижу примеров, где он дает хотя бы одно реальное преимущество. Вот ведь в чем незадача. А главное - те гениальные слова Булгакова о том, что "не то страшно, что человек смертен, а то, что иногда он внезапно смертен" - очень хорошо подходят к ПК. Был он, а потом "концепция изменилась". Здравствуй, геморрой. Насчет R3 - так они заставляют пользователей ожиться под систему, а не наоборот - я писал здесь про коробочный продукт.

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

> [229] Внук © (18.04.06 14:52)
> В смысле - я как раз про это писал, когда вел речь про коробочный
> продукт.

Как я тебя понимаю...
Жутко хочется писать именно коробочный вариант - чтобы пользователи покупали и прилаживались. Но вот не хотят они что-то. Приходится писать под заказчика со всеми вытекающими, например, часто модфицируемыми требованиями. В этом случае имхо СК лучше.

>>Суслик © (18.04.06 15:24) [230]
Да в этом и разница мнений. Устроились хорошо, пишут по-науке, буржуи, жируют :)) Теоретики.

> Внук © (18.04.06 14:51) [228]
>
> >>euru © (18.04.06 13:47)
> Понятно, спасибо за пример. Но в данном случае JOIN ничего
> не стОит базе данных, поскольку идет обрашение к одной записи
> из связанной таблицы по значению ПК - практически мгновенно.

Ну так это же был пример. Вместо одного документа может быть список документов. Более того, связь между документами может быть сложнее: цепочка может состоять не из 2-х документов, а из 3-4-х, а на каждый из этих документов могут быть наложены свои дополнительные ограничения.

> Насчет R3 - так они заставляют пользователей
> ожиться под систему, а не наоборот - я писал здесь про коробочный
> продукт.

SAP R/3 позволяет с нуля написать любую функциональность. Для этого в нём имеется встроенный объектно-ориентированный язык программирования (он, конечно, выглядит несколько необычно для привыкших к Delphi, C++, но в последних версиях можно писать и на Java). Только вот имеет ли смысл это делать, если уже имеются наработанные и проверенные во многих странах и на многих предприятиях решения?

> Да в этом и разница мнений. Устроились хорошо, пишут по-науке,
> буржуи, жируют :)) Теоретики.

или не пишут :)
или всего не говорят :)
или еще что-то :)

хотя, почему нет. Вполне могу допустить, что есть узкоспециализированные области в которых коробочное решение "работает".

Суслик © (18.04.06 16:45) [235]

> Вполне могу допустить, что есть узкоспециализированные области
> в которых коробочное решение "работает".

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

> [236] Игорь Шевченко © (18.04.06 17:04)
> А при большом желании можно допустить, что границы области,
> где коробочное решение работает (без кавычек), несколько
> шире, чем ты себе представляешь.

А вот у меня несколько иная информация:
1. 1с
2. r3
3. скала
4. аксапта
5. баан
6. системы бюждетирования (несколько у заказчиков стоят).

При том есть системы в виде коробочных решений:
1. windows2000server :)
2. windowsxp
3. Системы авторизации (ключики, флешки).
4. есть еще - но это то, что вспомнил.

Я полагаю, что о "коробочности" стоит говорить в определенном контексте задачи.

Суслик © (18.04.06 17:17) [237]

> Я полагаю, что о "коробочности" стоит говорить в определенном
> контексте задачи

Кто бы спорил. Точно так же, как и о применимости естественных и суррогатных ключей.

Игорь Шевченко © (18.04.06 17:19) [238]

К вопросу о производительности систем с СК и ЕК.

Я тот (см.выше) тестовый примерчик не поленился и проверил, хотя, если честно - лет 7-6 назад делал по заказу одной уважаемой орг-и тестирование нескольких движков и СУБД в сравнении др с др. (MS Jet, IB, Posgress, DBISAM, Paradox и др.)

Тогда я получил вполне внятный ответ на свои вопросы.
Сейчас ответ не изменился.

СК имеют преимущество в выборке.

Тест проводился на MS OLE ODBC и формате access.

В среднем время выборки на СК не зависит от сочетаний поисковых полей
и составляет на объеме 30 тыс записей 7 ms

Для ЕК время выборки зависит от порядка полей в PK (ну разумеется :))) и составляет от 7 до 70 ms.

В наихудшем случае при выборке всего объема время одинаково - 280 ms

Разумется, это всего лишь маленький и не обобщающий пример, но - пример.

P.S.
С увеличением числа записей инспектируемой таблицы ситуация будет улучшаться для СК.

Первичный ключ Найти похожие ветки