 | | | | |
| Синтетические и естественные ключи. |
Добрый день.
Может кто поможет мне определиться в том, какие ключи лучше
использовать в качестве первичных - синтетические или
естественные. Я прочитал несколько статей на эту тему, но не
уверен, что пришел к определенным выводам. С одной стороны
преимущество синтетического ключа кажется неоспоримым исходя из
того постулата, что любой объект реального мира подвержен
изменениям, иногда кардинальным. Очень многое из того, что
кажется незыблемым, может меняться и довольно быстро. Трудно
придумать действительно уникальный естественный ключ, например,
возьмем таблицу рабочих предприятия. Что взять в качестве
первичного ключа? Не буду говорить банальности о смене ФИО,
пола, паспорта и т.п. Взять за основу псевдо естественное поле
- табельный номер (ведь для того его и придумали)? А теперь
представьте ситуацию - предприятие работает долго, имеет
обширные архивы на CD-ROM, база эксплуатируется практически
непрерывно (вполне реальные параметры для серьезных баз данных).
Руководство отделов кадров решило, что теперь табельный номер
должен быть не числовой, а текстовой и нести в себе некую доп.
информацию (причем это с точки зрения программиста ситуация
весьма нестандартная, а с точки зрения отдела кадров проста и
менять свои взгляды на формат табельного номера оно может раз в
неделю, кстати, на период становления нового стандарта так оно и
будет). Что делать? Ну, в общем-то "что" понятно, но, боюсь, что
будет плохо и базе и программисту.
С другой стороны в примере с тем же табельным номером абсолютно
ясно, что он должен оставаться уникальным на протяжении всей
жизни базы и появление искусственного ключа мало того, что
нарушает правило нормализации, так еще и противоречит
фундаментальному философскому принципу Оккама - "сущности не
следует умножать без необходимости" ("Entities should not be
multiplied unnecessarily", William of Ockham). Я уж не говорю,
что в справочниках, как правило, тоже есть естественные
натуральные ключи, а их значения вставляются практически во все
таблицы. В таких случаях кажется неестественным организовывать
сложнейшие соединения таблиц по 10-20. Кроме того, чем больше
синтетических ключей в таблице, тем меньше она несет информации
сама по себе и тем больше чувствительна к потерям и ошибкам в
связанных таблицах.
Я постарался объяснить, почему ответ - "используй синтетические
ключи там, где нельзя использовать естественные", не кажется мне
разумным. Т.е. это тот случай, когда желательно все же не
действовать по принципу "и ты прав и ты тоже прав". Sergey
Всего в теме 290 сообщений
Добавить свое сообщение
Отслеживать это обсуждение 
| № 200 29-09-2009 15:09 |   |
Ответ на »сообщение 199« (Тимур и Ко)
___________________________
>>> Надо ли объяснять, что костыли нужны не тем, кто не испытывает проблем при ходьбе
Ну, зачем же сразу "костыли"? Я ходить умею, но не отказываюсь ни от автоинкрементых полей, ни от генераторов. Удобно.
Просто сначала люди еще колебались, какие ключи использовать. Свои преимущества были и у того, и у другого подхода. А сточки зрения поддержки со стороны СУБД оба подхода были равноценны. И каждый человек сам для себя решал, как лучше проектировать базы. Я после проб и ошибок склонился к искусственным ключам. Несмотря на наличе какадных обновлений, которые позволяли осуществлять связи по содержательным полям.
А теперь уже, наверное, и в голову никому не придет использовать естественные ключи (за исключением, разве что, особых экзотических случаев).
| № 199 29-09-2009 14:18 | |
Ответ на »сообщение 197« (Geo)
___________________________
Ответ на »сообщение 196« (glebbest)
___________________________
Сейчас же, насколько мне известно, в СУБД стали активно добаволяться и развиваться механизмы, ориентированные именно на искусственные первичные ключи.
Надо ли объяснять, что костыли нужны не тем, кто не испытывает проблем при ходьбе.
| № 198 29-09-2009 14:08 | |
и тем больше чувствительна к потерям и ошибкам в связанных таблицах. Т.е. предполагается, что в случае чего можно ручками подправить эксельную табличку. Если в табличке 1E6 записей, то ручки остануться в тумбочке.
Мне кажется, что и 10 лет назад ответ был очевиден, а сейчас ни кто просто не знает что такое Синтетические и естественные ключи. Для создания идентификаторов все пользуются стандартными средствами безо всякой философии.
| № 197 29-09-2009 08:15 | |
Ответ на »сообщение 196« (glebbest)
___________________________
>>> до сих пор толпами бродят неучи, считающие себя "специалистами в СУБД", которые не то чтобы
Э-э-э... А Вы вообще в теме? Или просто побурчать зашли? Дело в том, что каогда эта тема начиналась, то тенденции еще явно не наметились и шли грорячие споры между сторонниками естественных и искусственных первичных ключей. Сейчас же, насколько мне известно, в СУБД стали активно добаволяться и развиваться механизмы, ориентированные именно на искусственные первичные ключи. С этой точки зрения посмотреть на прошлый спор было бы очень интересно. А также выслушать мнение людей, ратовавших некогда за естественные ключи.
>>> даже вложенный запрос не могут написать
Ну, тут я Вам тоже могу язвительно ответить. Ходят тут люди, которые все проблемы решают исключительно вложенными запросами в надежде, что оптимизатор разберется и сделает как надо. А на то, чтобы грамотно выполнить JOIN нескольких таблиц, мозгов у них уже не хватает ;-)
>>> легион владельцев бумажек для подтирания с логотипом Oracle
Э-э-э... Oracle просто так бумажки не раздает. А работодателям имело бы смысл смотреть не только на наличие логотипа Oracle на бумажке, но и на то, что на этой бумажке написано. Может быть, кандидат показывает всего лишь фирменную туалетную бумагу, а вовсе не сертификат ;-)
| № 196 29-09-2009 06:52 | |
Ответ на »сообщение 195« (Geo)
___________________________
Бесполезно.
Я просто в недоумении: до сих пор толпами бродят неучи, считающие себя "специалистами в СУБД", которые не то чтобы разбираться в ключах, так даже вложенный запрос не могут написать. И обработку данных делают исключительно в циклах. А если этот цикл пишется не в С++, а в PL/SQL|SPL, то это ещё и готовый "профессионал программирования в PL/SQL|SPL". Найти бы это консервационное место и разбомбить...
PS: спасибо также дебилам из представительств вендоров СУБД в России/Украинt за тьму идиотов сертифицированных. Особо спасибо компании Oracle за дебилистическую программу сотрудничества с ВУЗ-ами и легион владельцев бумажек для подтирания с логотипом Oracle.
| № 195 23-09-2009 08:52 | |
Вообще-то, интеерсно было бы поднять это обсуждение шесть лет спустя и посомтреть, изменились ли за эти годы представления людей, ратовавших за использование естественных ключей ;-)
| № 194 23-09-2009 08:15 | |
2Сергей Тарасов:
Попытка решения задачи распределенных баз с помощью естественных первичных ключей - провал задачи распределенности. Ибо затраты на Вас, талантливого, занимающегося ручным разбором всех коллизий невозможности принятия очередного репликационного пакета с вставкой "дубля" по естественному ключу, будут катастрофическими.
Ибо задача распределенности баз требует гарантированного обмена без коллизий, а Вы, с такими ключами, будете генерировать их непрерывно. И не нужно рассказывать про супер-проектирование. В доморощенных системах его не существует.
Уникальные индексы на прикладные поля тоже в таких задачах не применяются. По той же причине. Окститесь.
Каскадные апдейты вообще испльзовать себе дороже - если есть хоть одна смежная система, обмен с ней рано или поздно именно из-за аких ключей станет долбичным и ручным.
Эй, апологеты "естественных" (и к тому же составных) ключей, Вы случайно в своих базах по контрагентам-физлицам первичным ключем не делает BLOB с фотографией физлица? Маниаки...
| № 193 14-05-2003 14:39 | |
Ключ у вахтёра
(Администрация)
Это объявление специально для полиции, чтоб не доставали.
У меня ключи обычно из одного поля. А уж суррогатный он при этом или естественный -- дело шестнадцатое.
| № 192 14-05-2003 10:50 | |
Предлагаю создать "Суррогатную полицию" которая будет врываться в оффисы, просить предьявить суррогатные ключи всех сущностей и проверять их подлинностью.
В случае непредьявления - штрафовать и вплоть до уголовной.
| № 191 14-05-2003 10:28 | |
Ответ на »сообщение 189« (Акжан Абдулин)
___________________________
Может, всё-таки, суррогатный?
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
|
