| | | | |
Синтетические и естественные ключи. |
Добрый день.
Может кто поможет мне определиться в том, какие ключи лучше
использовать в качестве первичных - синтетические или
естественные. Я прочитал несколько статей на эту тему, но не
уверен, что пришел к определенным выводам. С одной стороны
преимущество синтетического ключа кажется неоспоримым исходя из
того постулата, что любой объект реального мира подвержен
изменениям, иногда кардинальным. Очень многое из того, что
кажется незыблемым, может меняться и довольно быстро. Трудно
придумать действительно уникальный естественный ключ, например,
возьмем таблицу рабочих предприятия. Что взять в качестве
первичного ключа? Не буду говорить банальности о смене ФИО,
пола, паспорта и т.п. Взять за основу псевдо естественное поле
- табельный номер (ведь для того его и придумали)? А теперь
представьте ситуацию - предприятие работает долго, имеет
обширные архивы на CD-ROM, база эксплуатируется практически
непрерывно (вполне реальные параметры для серьезных баз данных).
Руководство отделов кадров решило, что теперь табельный номер
должен быть не числовой, а текстовой и нести в себе некую доп.
информацию (причем это с точки зрения программиста ситуация
весьма нестандартная, а с точки зрения отдела кадров проста и
менять свои взгляды на формат табельного номера оно может раз в
неделю, кстати, на период становления нового стандарта так оно и
будет). Что делать? Ну, в общем-то "что" понятно, но, боюсь, что
будет плохо и базе и программисту.
С другой стороны в примере с тем же табельным номером абсолютно
ясно, что он должен оставаться уникальным на протяжении всей
жизни базы и появление искусственного ключа мало того, что
нарушает правило нормализации, так еще и противоречит
фундаментальному философскому принципу Оккама - "сущности не
следует умножать без необходимости" ("Entities should not be
multiplied unnecessarily", William of Ockham). Я уж не говорю,
что в справочниках, как правило, тоже есть естественные
натуральные ключи, а их значения вставляются практически во все
таблицы. В таких случаях кажется неестественным организовывать
сложнейшие соединения таблиц по 10-20. Кроме того, чем больше
синтетических ключей в таблице, тем меньше она несет информации
сама по себе и тем больше чувствительна к потерям и ошибкам в
связанных таблицах.
Я постарался объяснить, почему ответ - "используй синтетические
ключи там, где нельзя использовать естественные", не кажется мне
разумным. Т.е. это тот случай, когда желательно все же не
действовать по принципу "и ты прав и ты тоже прав". Sergey
Всего в теме 290 сообщений
Добавить свое сообщение
Отслеживать это обсуждение
№ 240 01-10-2009 11:48 | |
Ответ на »сообщение 238« (Как слышно? Приём!)
___________________________
>>> Как говорилось в анекдоте про три стакана водки на заводе: "так ведь работаю же!"
Если работать после трех стаканов водки, то в резульаье получим продукт, произведенный после трех стаканов водки.
Автоматизация хаоса может привести только к возникновению автоматизированного хаоса.
№ 239 01-10-2009 11:46 | |
Ответ на »сообщение 237« (Как слышно? Приём!)
___________________________
>>> Идея Госплана СССР витает в воздухе :)
Я, конечно, понимаю, что Госплан СССР -- это порождение большевистской диктатуры и поэтому его идеи являются плохими по определению. Но неужели Вы думаете, что венец творения подлинно демократического общества -- транснациональные корпорации -- устроены по-другому? У них, наверное, совет директоров сам по себе, региональные организации сами по себе, подразделения тоже сами по себе, так что ли? ;-)
Это не Госплан, и не ТНК. Это принципы иерархической организации и управления. Это единственное, что пока смогло придумать человечество для организации крупных систем.
Если для каких-то элементов структуры нужно что-то, то это что-то вводится в таком из узлов иерархии (желательно самом низком), что все "потребители" принадлежат его нижнему замыканию. Если же это что-то удобнее вводить в одном из более низких узлов (ну, покупатель пришел в магазин, а не в центральный офис), то все равно внесенная информация передается наверх, а оттуда транслируется всем остальным.
И знаете, все работает ;-)
>>> Правильно фамилия:Пупкин имя:Василий
Хех! А человеческий фактор? Вы уверены, что какая-нибудь блондинка не перепутает имя с фамилией (в смысле, что куда вносить)? Или по старой чатовской привычке возьмет и напишет имя и фамилию капсом? А Вы уверены, что если придет покупатель, которого зовут Рамиз Мамед Наби Оглы, то операторша сможет правильно определить, что здесь имя, а что -- фамилия?
А именами людей проблема не исчерпывается. Вот я работал в организации, которая имела форму АНО и называлась Корпорация МетаСинтез. Знаете, сколько вариантов написания только я лично видел, когда информацию об организации заносили в ту или иную БД?
№ 238 01-10-2009 11:02 | |
Ответ на »сообщение 235« (Cepгей Poщин)
___________________________
>>> автоматизировать бедлам невозможно
Как говорилось в анекдоте про три стакана водки на заводе: "так ведь работаю же!"
Автоматизировать идеальный объект удобнее, что и говорить.
№ 237 01-10-2009 10:59 | |
Ответ на »сообщение 236« (Geo)
___________________________
>>> А они не должны вводиться независимо.
Идея Госплана СССР витает в воздухе :)
>>> Сначала одна девочка записала клиента как "Вася Пупкин". В следующий раз другая занесла его как "Пупкин Вася". А потом третья опечаталась и занесла его как "Пукин Вася".
Правильно фамилия:Пупкин имя:Василий
Как в паспорте.
А вот Пукин - выходит за рамки противостояния естественных и искусственных ключей.
№ 236 01-10-2009 09:41 | |
Ответ на »сообщение 234« (Как слышно? Приём!)
___________________________
>>> если вводились независимо
А они не должны вводиться независимо. Если клиент обращаетя в магазин, то он заносится в том магазине, куда он обратился. Если есть общий справочник товаров, то он должен заноситься в центральном подразделении, которое отвечает за подбор товаров.
А ситуации, когда клиент сначала идет в один магазин (где его регистрируют), а через неделю -- в другой (где его снова регистрируют) в общем случае технически неразрешимы. Для этого никаких распрелделнных БД не надо. Пусть у нас есть один комп и база на нем. Сначала одна девочка записала клиента как "Вася Пупкин". В следующий раз другая занесла его как "Пупкин Вася". А потом третья опечаталась и занесла его как "Пукин Вася". Обсуждение данной проблемы выходит за рамки противостояния естественных и искусственных ключей.
№ 235 01-10-2009 09:39 | |
Ответ на »сообщение 234« (Как слышно? Приём!)
___________________________
NewId1 = NextVal1 + 1E9 * IdDB1 = 1 + 1000000000 * 1 = 1000000001
NewId2 = NextVal2 + 1E9 * IdDB2 = 1 + 1000000000 * 2 = 2000000001
IdDB1 и IdDB2 единократно при создании БД выдаются. Если нет ни какой организации вообще и IdDB тоже лепят кому как захочется, то... как уже говорилось неоднократно: автоматизировать бедлам невозможно.
№ 234 01-10-2009 09:30 | |
Ответ на »сообщение 230« (Cepгей Poщин)
___________________________
>>> 1. в каждой БД хранится идентификатор этой самой базы IdDB, который задаётся централизовано при создании этой самой БД.
>>> NewId = NextVal + 1E9 * IdDB
Так о том и речь.
Одно и то же глюкало будет после слияния с ключом NewId1 = NextVal1 + 1E9 * IdDB1
и под ключом NewId2 = NextVal2 + 1E9 * IdDB2, если вводились независимо.
А так: глючало и глюкало - ясно автоматом, что одно и то же и без "исправлять ручками".
№ 233 01-10-2009 08:31 | |
Ответ на »сообщение 232« (Как слышно? Приём!)
___________________________
>>> Понятное дело, если обмен данными осуществляется с помощью текстовых файликов
Намек на XML? Намёк на то, что в некоторых организациях до сих пор в филиалах набирают тот же список клиентов в виде таблички excel, или просто текст набивают. Потом отправляют в центр, а там в конце года, вместо всенародных праздников, начинается поиск двойников и мёртвых душ.
Т.е. при обмене данными между разными БД, вопрос стоит не "что лучше?", а "возможно ли?" использовать идентификаторы. Если невозможно то ни чего другого не остаётся.
№ 232 01-10-2009 07:41 | |
Ответ на »сообщение 230« (Cepгей Poщин)
___________________________
>>> Понятное дело, если обмен данными осуществляется с помощью текстовых файликов
Намек на XML?
№ 231 01-10-2009 05:17 | |
Ответ на »сообщение 229« (Как слышно? Приём!)
___________________________
Восстановление после сбоя данных, организованных через абстрактный индекс по третьей норме
может быть основано лишь на резервном копировании. Уже говорил на эту тему: если речь не о БД учета носков всей семьи, то других вариантов нет. Перебирать, анализировать и исправлять ручками миллион записей — это не программирование, а сизифовЪ труд.
Дальше я не понял, что мы такое выигрываем от использования естесственный ключей....
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|
|