 | | | | |
| Синтетические и естественные ключи. |
Добрый день.
Может кто поможет мне определиться в том, какие ключи лучше
использовать в качестве первичных - синтетические или
естественные. Я прочитал несколько статей на эту тему, но не
уверен, что пришел к определенным выводам. С одной стороны
преимущество синтетического ключа кажется неоспоримым исходя из
того постулата, что любой объект реального мира подвержен
изменениям, иногда кардинальным. Очень многое из того, что
кажется незыблемым, может меняться и довольно быстро. Трудно
придумать действительно уникальный естественный ключ, например,
возьмем таблицу рабочих предприятия. Что взять в качестве
первичного ключа? Не буду говорить банальности о смене ФИО,
пола, паспорта и т.п. Взять за основу псевдо естественное поле
- табельный номер (ведь для того его и придумали)? А теперь
представьте ситуацию - предприятие работает долго, имеет
обширные архивы на CD-ROM, база эксплуатируется практически
непрерывно (вполне реальные параметры для серьезных баз данных).
Руководство отделов кадров решило, что теперь табельный номер
должен быть не числовой, а текстовой и нести в себе некую доп.
информацию (причем это с точки зрения программиста ситуация
весьма нестандартная, а с точки зрения отдела кадров проста и
менять свои взгляды на формат табельного номера оно может раз в
неделю, кстати, на период становления нового стандарта так оно и
будет). Что делать? Ну, в общем-то "что" понятно, но, боюсь, что
будет плохо и базе и программисту.
С другой стороны в примере с тем же табельным номером абсолютно
ясно, что он должен оставаться уникальным на протяжении всей
жизни базы и появление искусственного ключа мало того, что
нарушает правило нормализации, так еще и противоречит
фундаментальному философскому принципу Оккама - "сущности не
следует умножать без необходимости" ("Entities should not be
multiplied unnecessarily", William of Ockham). Я уж не говорю,
что в справочниках, как правило, тоже есть естественные
натуральные ключи, а их значения вставляются практически во все
таблицы. В таких случаях кажется неестественным организовывать
сложнейшие соединения таблиц по 10-20. Кроме того, чем больше
синтетических ключей в таблице, тем меньше она несет информации
сама по себе и тем больше чувствительна к потерям и ошибкам в
связанных таблицах.
Я постарался объяснить, почему ответ - "используй синтетические
ключи там, где нельзя использовать естественные", не кажется мне
разумным. Т.е. это тот случай, когда желательно все же не
действовать по принципу "и ты прав и ты тоже прав". Sergey
Всего в теме 290 сообщений
Добавить свое сообщение
Отслеживать это обсуждение 
| № 190 14-05-2003 05:58 |   |
Ответ на »сообщение 189« (Акжан Абдулин)
___________________________
Какая обиженная сторона, Акжан ? Здесь же не выборы.
Это просто интересная информация, отражающая текущее положение дел.
| № 189 14-05-2003 04:46 | |
Только не голосование :-)
Иначе обиженная сторона справедливо заметит, что "миллионы леммингов не могут ошибаться". Если бы голосование отражало профессиональный опыт...
Кстати, необходимо учесть, что в любой системе будет хотя бы один синтетический ключ. Хотя бы для деревьев.
| № 188 13-05-2003 13:30 | |
Ответ на »сообщение 187« (Сергей Тарасов)
___________________________
К сожалению или у счастью - кому как, но такие вопросы голосованием не решаются.
Сергей, но ведь мы ничего не решаем! Это для разрядки после такого долгого обсуждения :о))
Возможно, кому-то оно пригодиться. Но большая часть все равно не станет менять свои предпочтения... Я, например, не стану :о)
| № 187 13-05-2003 13:12 | |
Ответ на »сообщение 186« (Елена Филиппова)
___________________________
К сожалению или у счастью - кому как, но такие вопросы голосованием не решаются.
| № 186 13-05-2003 13:10 | |
Ответ на »сообщение 185« (Jack Of Shadows)
___________________________
Да надо закрыть к черту эту ветку и просто обьявить голосование кто что использует. Тема себя исчерпала.
Давайте уточним варианты для голосования.
То, что Вы предлолжили в »сообщение 144 в теме №70 на БП« :
- использую только синтетические ключи
- использую только естественные ключи
- использую и то и другое по обстановке
- что такое ключ ?
| № 185 13-05-2003 04:18 | |
Да надо закрыть к черту эту ветку и просто обьявить голосование кто что использует. Тема себя исчерпала.
| № 184 12-05-2003 15:22 | |
"На колу мочало - начинай сначала"
:)))
| № 183 12-05-2003 15:16 | |
Насчет естественных ключей и почему в 99% с ними не стоит связываться
1) Миф об ИНН - уникальный и т.д. Организация имеет несколько филиалов которые разняться только по КПП (ИНН общий) Но эти филиалы у них (у каждого!!!) свой расчетный счет свое наименование... каждое закупает материалы у нас. Вопрос как мне формировать естетвенный ключ??? как ИНН/КПП + плюс количество волос на голове директора? З.Ы. они просят акты сверки делать по каждому
В добавок чуете как размер первичного ключа растет??? Ведь таких клиентов <<1%
Я ввожу обычный орокловский Sequence и все в порядке.
2) Номер выписанной нами счет- фактуры уникален.. Зам. Главбуха пришла в голову идея номера с/ф должны идти по порядку по датам.... Девочка набивальщица ошиблась перепутала даты.... представте себе объем ее работы по исправлению
чтобы поменять местами с/ф №2002005687 и №2002005688
3)Подошел к нашему снабженцу Леха тебе как удобней код гайки как 111222898 или ГШ45-567
Ответ: По барабану я че осел коды запоминать!!!!! (справочник материалов--- древовидная структура в ведение снабженцев)
Когда есть естественный ключ он забивается как один из аттрибутов объекта и не более!!!
4) Сам сталкивался существуют разные фирмы с одинаковым наименованием в одном городе (к вопросу об дублирующих записях)
так что в последствии от ЕК и ИК одни проблемы.....
Сообщение не подписано
| № 182 12-05-2003 14:53 | |
Насчет естественных ключей и почему в 99% с ними не стоит связываться
1) Миф об ИНН - уникальный
| № 181 08-05-2003 23:12 | |
Акжан:
40% это практически бесплатно за реализацию Великой Мечты автоматизировать хаос.
>рассматривать метаданные как свойство объекта неверно
там предполагается что получив в качестве значения ID другого объекта мы можем не иметь никакого контекста о том что это за объект, а запись (коллекция, элемент, ID) из которой можно получить ID коллекции т.е. тип нашего объекта это не совсем (объект, свойство, значение). Сейчас не помню, может быть таблица даже не проиндексирована по третьему полю. Идея такова что "избавляемся от энтропии" мы всегда двигаясь слева направо. Очевидно там что-то неладно.
Возвращаясь к топику скажу что РСУБД это все-таки база именно данных - отдельно информация и отдельно фиксированная струтура которая нагружает голые биты семантико, а не самоопивывающееся спроси-его-что-оно-такое. Если мы храним бухгалтерию там должны быть названия и суммы. Если храним граф то там должны быть только ID, о чем говорит Trurl. Если в обычной базе появляются ID то прикладной программист берет на себя функции разработчика самой subd.exe, это вообще несколько другая профессия.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
|
