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

← →
Игорь Шевченко © (2006-04-20 12:02) [360]

sniknik © (20.04.06 11:35) [356]

> и теперь представьте ситуацию, клиент "заартачился",

Даже представлять не буду. Если под каждого клиента навешивать свои рюшечки, это значит, обрекать себя на непроизводительный геморрой. А оно надо ?

← →
xayam © (2006-04-20 12:08) [361]

> Игорь Шевченко © (20.04.06 12:02) [360]
> А оно надо ?

Тебе вроде за это деньги платят. Или нет?

← →
sniknik © (2006-04-20 12:22) [362]

> А оно надо ?
надо. если хотите заполучить больше клиентов и включить в сферу деятельности например Бурятию...

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

p.s. на этот раз окончательный ;о), никто никого не переубедит.... в общемто [356] это не попытка переубеждений а запоздалый ответ на вопрос "почему с искуственным исправить сложнее".

← →
vovnuke © (2006-04-20 12:52) [363]

> [210] euru © (18.04.06 11:39)

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

> [336] Игорь Шевченко © (20.04.06 00:53)
> А какой смысл держать два уникальных constraint в одной
> сущности ?

Один для базы данных, другой для польщователя.

← →
Хозяин (2006-04-20 13:05) [364]

Я правильно понял?
ID Pole_ISO Pole_Rus Pole_Eng Pole_Fr ...
0 RU Россия Russia La Russie Rusia Ru?land
1 UK ...

видимо так...
Pole_local_ISO Pole_removed_ISO Pole_Country_Name RU FR Франция RU US США FR RU La Russie FR US La America US RU Russia US FR France ...

← →
Внук © (2006-04-20 13:09) [365]

Removed и Remote - это разные слова :)

← →
Хозяин (2006-04-20 13:12) [366]

Внук © :)
да я сомневался, ну и "сократом" - сократнул :) (удаленный)

← →
Игорь Шевченко © (2006-04-20 13:18) [367]

sniknik © (20.04.06 12:22) [362]

> надо. если хотите заполучить больше клиентов

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

← →
xayam © (2006-04-20 13:21) [368]

> Игорь Шевченко © (20.04.06 13:18) [367]
> Да мы не жалуемся.

Значит Вы ничего не делаете

> Спор какой-то из-за выеденного яйца

Отдели структуру базы от содержания и спора не будет

> Не зная задачи, не зная области применения

раскрой тайну

> Детский сад, штаны на лямках, ей-богу

несерьезно говоришь

← →
Игорь Шевченко © (2006-04-20 13:24) [369]

xayam © (20.04.06 13:21) [368]

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

← →
xayam © (2006-04-20 13:26) [370]

> Игорь Шевченко © (20.04.06 13:24) [369]
> не зная ничего ни об области применения, ни о решаемых задачах

если ты этого еще не понял, то это не важно по большому счету, я говорю "БЕЗОТНОСИТЕЛЬНО К ЗАДАЧИ"

← →
xayam © (2006-04-20 13:28) [371]

> их возможность была бы убрана производителями СУБД

каким образом?

← →
Игорь Шевченко © (2006-04-20 13:36) [372]

> если ты этого еще не понял, то это не важно по большому
> счету, я говорю "БЕЗОТНОСИТЕЛЬНО К ЗАДАЧИ"

Ну прочитай ты, что люди пишут.

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

А потом говори про безотносительность.

← →
vovnuke © (2006-04-20 13:36) [373]

> [369] Игорь Шевченко © (20.04.06 13:24)

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

← →
Игорь Шевченко © (2006-04-20 13:38) [374]

vovnuke © (20.04.06 13:36) [373]

> И надо каждые из них использовать в своей области.

Ну объясни ты мне, какой смысл городить огород из искусственных ключей, вводить дополнительные объекты, если в предметной области уже присутствуют атрибуты, подходящие на роль ключей. Объяснить желательно цитатой из Кодда.

← →
vovnuke © (2006-04-20 13:49) [375]

> [374] Игорь Шевченко © (20.04.06 13:38)

Если вы придерживаться терминологии, используемой в http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf, то тогда мы с вами про разные вещи разговариваем.
Придерживаясь этой терминологиии:
- под искусственным ключом я понимаю:
"внутренние ключи" полученные искусственным образом,
- под естественным ключом "бизнес ключ", а вот бизнес ключом может быть как "искусственные" так и "естественные", что уже зависит от поставленной задачи.

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

← →
xayam © (2006-04-20 13:51) [376]

> Игорь Шевченко © (20.04.06 13:36) [372]

"...Значение искусственного ключа формируется в БД и публикуется для использования во внешнем мире. Обратно, естественный ключ формируется неким сторонним для БД источником..."
это никак не должно быть связано со структурой базы
"...Понятно, что относительно этого источника ключ будет искусственным. Т.е если в одной БД ключ естественный, то где-то существует информационная система, где он является искусственным, ибо никто и ничто не рождается и не возникает с готовым именем или номером..."
где-то это где?
"...Люди, компании, планеты, показания датчиков, получают имена и иные «естественные» ключи посредством регистрации некоторой признанной организацией. По своему масштабу этой организацией может быть международное агентство по поддержке стандарта ISO 3166..."
может, а может и не быть, об этом уже говорили

← →
Внук © (2006-04-20 13:53) [377]

>>Игорь Шевченко © (20.04.06 13:38) [374]
А Кодду мы верим, поскольку это никакая не религия :)

← →
Игорь Шевченко © (2006-04-20 14:11) [378]

xayam © (20.04.06 13:51) [376]

Это вопросы мне или автору статьи ?

vovnuke © (20.04.06 13:49) [375]

Изначально в этой ветке разговор шел только о двух типах ключей - естественных и искусственных. Под искусственными здесь понимались ключи, сгенерированные конкретной базой данных для обеспечения уникальности и удобства связи таблиц. Корректируя свою мысль, в соответствии с [375], я говорю, что не только сгенерированные базой данных значения являются кандидатами на роль первичных ключей для таблиц, а и те, которые по терминологии из http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf называются бизнес-ключами или естественными ключами.

Внук © (20.04.06 13:53) [377]

А Кодд приводит более убедительные доводы, чем высказывания в ветке.

← →
Внук © (2006-04-20 14:13) [379]

>>Игорь Шевченко © (20.04.06 14:11) [378]
А пророки всегда убедительнее. Это я тебе как краевед :)

← →
xayam © (2006-04-20 14:14) [380]

> Игорь Шевченко © (20.04.06 14:11) [378]
> xayam © (20.04.06 13:51) [376]
> Это вопросы мне или автору статьи ?

К тебе. Ты же него ссылаешься. Поэтому я тебе его словами говорю.

← →
Игорь Шевченко © (2006-04-20 14:29) [381]

Внук © (20.04.06 14:13) [379]

Так апостолы же не приводят убедительных доводов. Вот и приходится к первоисточникам обращаться.

xayam © (20.04.06 13:51) [376]

> естественный ключ формируется неким сторонним для БД источником.
> .."
> это никак не должно быть связано со структурой базы

Почему, из каких соображений это не должно быть ?

> где-то это где?

Где-то - это в другой системе.
Например, в информационной системе ISO.

> может, а может и не быть, об этом уже говорили

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

← →
vovnuke © (2006-04-20 14:30) [382]

2 [378] Игорь Шевченко © (20.04.06 14:11)

> не только сгенерированные базой данных значения являются
> кандидатами на роль первичных ключей для таблиц, а и те,
> которые по терминологии из http://www.ncom.ru/downloads/KeyTaxonomy2005ru.pdf
> называются бизнес-ключами или естественными ключами

Вот здесь я с вами не согласен, так как говоря вашими словами:

> [341] Игорь Шевченко © (20.04.06 01:18)
> каждый овощ приносит пользу, будучи употреблен
> надлежащим образом в надлежащее время

База должна работать со своими атрибутами пользователь со своими, и не надо смешивать эти вещи.

← →
xayam © (2006-04-20 14:37) [383]

> Игорь Шевченко © (20.04.06 14:29) [381]
> из каких соображений это не должно быть ?

Так ну свои соображения уже приводил. Теперь по Кодду. Как там у него? 12 правил. Напомни 9-11 пожалуйста.
"9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы не должны зависеть от логических ограничений.
10. НЕЗАВИСИМОСТЬ КОНТРОЛЯ ЦЕЛОСТНОСТИ. Все необходимое для поддержания целостности данных, должно храниться в словаре данных.
11. ДИСТРИБУТИВНАЯ НЕЗАВИСИМОСТЬ. Реляционная БД должна быть переносимой и способной к распространению."
Вроде так? Или нет?

← →
Игорь Шевченко © (2006-04-20 14:40) [384]

xayam © (20.04.06 14:37) [383]

Все правильно. Использование естественных или бизнес-ключей этим правилам не противоречит. Независимость налицо, переносимость налицо, поддержка целостности налицо.

vovnuke © (20.04.06 14:30) [382]

> База должна работать со своими атрибутами пользователь со
> своими, и не надо смешивать эти вещи

На основании чего делается такой вывод ? (Кто с чем должен работать и почему не надо смешивать) ?

← →
euru © (2006-04-20 14:51) [385]

> vovnuke © (20.04.06 12:52) [363]
> > [210] euru © (18.04.06 11:39)
> Покажите мне пожалуйста хоть один пример реально удачного
> внедрения этой системы в России.
Ну, например, у нас. :)

← →
xayam © (2006-04-20 14:51) [386]

> Игорь Шевченко © (20.04.06 14:40) [384]
> "...10. НЕЗАВИСИМОСТЬ КОНТРОЛЯ ЦЕЛОСТНОСТИ. Все необходимое
> для поддержания целостности данных, должно храниться в словаре
> данных..."

Да о каком контроле ты можешь говорить? Ты что можешь контролировать другую базу? Так что ли?

> "...11. ДИСТРИБУТИВНАЯ НЕЗАВИСИМОСТЬ. Реляционная БД должна
> быть переносимой и способной к распространению..."

Заметь без всяких условий, есть ISO или нет его, базе на это вообще с большой горы...

> "...9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы
> не должны зависеть от логических ограничений..."

Мутно конечно написано у Кодда, но ему это простительно, он же хотел все охватить! Как я это понимаю - это как раз "отделить мух от котлет" или "структуру от содержания" или "база должна работать со своими атрибутами пользователь со своими" - все одно и тоже.

← →
euru © (2006-04-20 14:59) [387]

> xayam © (20.04.06 14:37) [383]
> Так ну свои соображения уже приводил. Теперь по Кодду. Как
> там у него? 12 правил. Напомни 9-11 пожалуйста.
> "9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы
> не должны зависеть от логических ограничений.
> 10. НЕЗАВИСИМОСТЬ КОНТРОЛЯ ЦЕЛОСТНОСТИ. Все необходимое
> для поддержания целостности данных, должно храниться в словаре
> данных.
> 11. ДИСТРИБУТИВНАЯ НЕЗАВИСИМОСТЬ. Реляционная БД должна
> быть переносимой и способной к распространению."

Обратим внимание на то, что "всё необходимое ... должно храниться в словаре данных".Словарь данных и структура БД -- это две большие разницы.

← →
Игорь Шевченко © (2006-04-20 15:11) [388]

xayam © (20.04.06 14:51) [386]

> Да о каком контроле ты можешь говорить? Ты что можешь контролировать
> другую базу? Так что ли?

Конечно. Использование стандарта автоматически обеспечивает контроль.

> Как я это понимаю

Ты ошибаешься и придаешь не тот смысл высказыванию Кодда.

> Игорь Шевченко © (20.04.06 15:11) [388]
> Использование стандарта автоматически обеспечивает контроль.

в том то и дело, что НЕТ.

> > Как я это понимаю
> Ты ошибаешься и придаешь не тот смысл высказыванию Кодда.

расскажи о своем понимании

> [385] euru © (20.04.06 14:51)
> Ну, например, у нас. :)

Это, простите что за компания? Сколько времени она у вас внедрялась? Сколько было положено сил для адаптации данной системы под Россию? И на самом ли деле она так уж хорошо работает? И стоит ли она своих денег?

> [384] Игорь Шевченко © (20.04.06 14:40)
> На основании чего делается такой вывод ? (Кто с чем должен
> работать и почему не надо смешивать) ?

см.

> [386] xayam © (20.04.06 14:51)
> > "...9. ЛОГИЧЕСКАЯ НЕЗАВИСИМОСТЬ ДАННЫХ. Прикладные программы
>
> > не должны зависеть от логических ограничений..."

плюс, собственное понимание проблемы. Это не верно - смешивать функции атрибутов базы данных с функциями атрибутов, которые необходимы для работы пользователей. Перегрузка.

Молоток тоже универсальный инструмент, им тоже можно много чего делать, но это не значит чтоэто нужно делать.

xayam © (20.04.06 15:14) [389]

> в том то и дело, что НЕТ.

Почему же ? Если каждая база обеспечивает соответствие географическому понятию кода ISO, то почему контроля-то нет ?

> Прикладные программы
> > не должны зависеть от логических ограничений..."

> расскажи о своем понимании

А я понимаю буквально, как написано.

vovnuke © (20.04.06 15:17) [390]

> Это не верно - смешивать функции атрибутов базы данных с
> функциями атрибутов, которые необходимы для работы пользователей

Дорогой друг, объясни пожалуйста, почему не верно. Мне впрямь интересно. Кроме того, с базой работают не сколько пользователи, сколько программы.

> . Перегрузка.

Перегрузка ЧЕГО ? Пользователей, базы, программы ? О какой перегрузке идет речь и почему не идет речь о перегрузке, когда согласно канонам требуется вводить дополнительные поля для обеспечения уникальности уникальных значений ?

> vovnuke © (20.04.06 15:17) [390]
> Это, простите что за компания? Сколько времени она у вас
> внедрялась? Сколько было положено сил для адаптации данной
> системы под Россию? И на самом ли деле она так уж хорошо
> работает? И стоит ли она своих денег?

1. Коммерческая.
2. Внедрение заняло 1 год.
3. SAP R/3 уже давно адаптирован под Российское законодательство, так что сил на адаптацию практически затрачено не было. Здесь главное не изобретать велосипед, а использовать уже наработанное.
4. На работу не жалуемся. На данный момент в системе работает 3 завода, к июлю ещё 2 присоединится. Также планируется расширение спектра решаемых системой задач.
5. Я думаю, если бы это было невыгодно, руководство компании не думало бы о расширении системы.

> Игорь Шевченко ©

Ладно, мне кажется уже все сказано, каждый остался при своем. Думал до [1000] доживу, не получается, это переходит в болтовню. Спасибо за внимание. Всем удачи. Тебе, Игорь, отдельно. Нас ведь не забудут? Может даже прочитают от начала до конца))

> [393] Игорь Шевченко © (20.04.06 15:28)

> с базой работают не сколько пользователи, сколько программы.

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

> Перегрузка ЧЕГО

Перегрузка функций, которые выполняют те или иные атрибуты. см. [391].

> для обеспечения уникальности уникальных значений

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

2Игорь

> Перегрузка ЧЕГО ? Пользователей, базы, программы ? О какой
> перегрузке идет речь и почему не идет речь о перегрузке,
> когда согласно канонам требуется вводить дополнительные
> поля для обеспечения уникальности уникальных значений ?

Дай я попробую объяснить.
ДОпустим у тебя есть в БД только одна таблица. Тогда, действительно, можно обойтись без СК - взять ЕК (если найдется такое поле).
Представь, что у тебя в БД 10^3 таблиц (бывает же такое - спорить не будешь?). Есть таблица - справочник чего-то с ключем - ИНН. На эту таблицу по FK ссылаются 10^2 таблиц (такое же тоже бывает - спорить не будешь?). ИНН это скорее всего число 8 байт (вряд ли 4, т.к. столько там знаков 10 кажется?). Получается, что в таблицах, которые ссылаются на свой справочник будут тратиться лишние 4 байта на каждую ссылку. Это ли не перегрузака? Тут вряд ли можно поспорить. Если можно, то объясни :)

Да, ты можель возразить, что видите ли твои ISO это всего 3 знака. Ну хорошо. Можем и на это заложиться. Т.е. здесь вроде как перегрузки нет, если будем использовать ЕК на основе кода ISO.

В этом случае приведу тебе пример. Ты помнишь, что было с автономерами, вернее кодами регионов? Сначала было 2 цифры (77, 99), потом стало 3 (177). Сам понимаешь, что если бы ты для региона заложился на 1 байт (т.е. 256 максимум) то сейчас бы ты был в ..., ну т.е. пришлось бы много чего менять.

А у тебя есть уверенность в том, что через год коды ISO не станут строками? Ну например, распадется какая нить республика на 10^2 стран и для того, чтобы не плодить новых номеров из назовут примерно так - 055а, 055б и т.д.

Вот к чему я веду - оно тебе надо думать над такими проблемами (а что будет, а надежен ли такой ключ и пр.), если есть проверенное и ВСЕГДА работающее решение - СК?

> [394] euru © (20.04.06 15:34)

Ну, значит я несколько отстал? Или, действительно, данную систему реально адаптировали под Россию.

Присоединяюсь к

> [395] xayam © (20.04.06 15:35)

Но если есть еще что сказать по существу, то с удовольствием послушаю.

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