 | | | | |
| Синтетические и естественные ключи. |
Добрый день.
Может кто поможет мне определиться в том, какие ключи лучше
использовать в качестве первичных - синтетические или
естественные. Я прочитал несколько статей на эту тему, но не
уверен, что пришел к определенным выводам. С одной стороны
преимущество синтетического ключа кажется неоспоримым исходя из
того постулата, что любой объект реального мира подвержен
изменениям, иногда кардинальным. Очень многое из того, что
кажется незыблемым, может меняться и довольно быстро. Трудно
придумать действительно уникальный естественный ключ, например,
возьмем таблицу рабочих предприятия. Что взять в качестве
первичного ключа? Не буду говорить банальности о смене ФИО,
пола, паспорта и т.п. Взять за основу псевдо естественное поле
- табельный номер (ведь для того его и придумали)? А теперь
представьте ситуацию - предприятие работает долго, имеет
обширные архивы на CD-ROM, база эксплуатируется практически
непрерывно (вполне реальные параметры для серьезных баз данных).
Руководство отделов кадров решило, что теперь табельный номер
должен быть не числовой, а текстовой и нести в себе некую доп.
информацию (причем это с точки зрения программиста ситуация
весьма нестандартная, а с точки зрения отдела кадров проста и
менять свои взгляды на формат табельного номера оно может раз в
неделю, кстати, на период становления нового стандарта так оно и
будет). Что делать? Ну, в общем-то "что" понятно, но, боюсь, что
будет плохо и базе и программисту.
С другой стороны в примере с тем же табельным номером абсолютно
ясно, что он должен оставаться уникальным на протяжении всей
жизни базы и появление искусственного ключа мало того, что
нарушает правило нормализации, так еще и противоречит
фундаментальному философскому принципу Оккама - "сущности не
следует умножать без необходимости" ("Entities should not be
multiplied unnecessarily", William of Ockham). Я уж не говорю,
что в справочниках, как правило, тоже есть естественные
натуральные ключи, а их значения вставляются практически во все
таблицы. В таких случаях кажется неестественным организовывать
сложнейшие соединения таблиц по 10-20. Кроме того, чем больше
синтетических ключей в таблице, тем меньше она несет информации
сама по себе и тем больше чувствительна к потерям и ошибкам в
связанных таблицах.
Я постарался объяснить, почему ответ - "используй синтетические
ключи там, где нельзя использовать естественные", не кажется мне
разумным. Т.е. это тот случай, когда желательно все же не
действовать по принципу "и ты прав и ты тоже прав". Sergey
Всего в теме 290 сообщений
Добавить свое сообщение
Отслеживать это обсуждение  <<<... | 280—271 | 270—261 | ...>>>
Всего сообщений в теме: 290; страниц: 29; текущая страница: 2
| № 280 05-10-2009 08:13 |   |
"В действительности правила столь строги, что все популярные т. н. «реляционные» СУБД не соответствуют многим критериям".
см.( http://ru.wikipedia.org/wiki/12_правил_Кодда )
Так что реальные БД замараны грязными руками недоучек
по сравнению с сияющими вершинами математических принципов :)
Так что аргумент научности реляционных БД не проходит.
| № 279 05-10-2009 07:51 | |
Лень заглянуть на соседнюю ветку?
Ладно, кофе в постель.
"Живые формы информационных структур не могут быть верно представлены иерархией".
(С) Тед Нельсон.
| № 278 05-10-2009 07:49 | |
Ответ на »сообщение 276« (Сергей Перовский)
___________________________
>>> Другое дело, что со временем в программистскую индустрию пришли люди без серьезной математической подготовки.
>>> И в "реляционные" СУБД начали вносить "улучшения", которые не укладывались в математический аппарат, приводили к неоднозначности
Понятно.
"Дух призмы Оберона".
Не формальные методы буксуют в неформальном мире, а недоучки виноваты.
Все, кто с нами несогласен - недоучки.
Аргумент.
| № 277 05-10-2009 07:01 | |
Ответ на »сообщение 276« (Сергей Перовский)
___________________________
>>> И в "реляционные" СУБД начали вносить "улучшения", которые не укладывались в математический аппарат, приводили к неоднозначности и т.д.
Делаем вывод, что в разработке СУБД дело обстоит точно так же, как и в остальном IT :D
| № 276 05-10-2009 06:07 | |
Ответ на »сообщение 274« (Как слышно? Приём!)
___________________________
Ответ на »сообщение 253« (Geo)
___________________________
>>> Цели введения сетевых БД не определены. Само понятие тоже не определено
Вот тут есть немножко:
http://www.codenet.ru/db/oracle/oraclepr_03.php
Я бы описал эту историю несколько иначе.
Поскольку модели могут иметь иерархическую или сетевую структуру, первые попытки создания СУБД были направлены на прямое отображение той или иной модели в структуру данных. Инструмент непосредственно соответствовал выбранной модели.
Кодд предложил математическую модель, которая была пригодна для описания как иерархических, так и сетевых систем. Реляционная алгебра не язык, как указано в статье, а математическая теория, предоставляющая строгий, полный и непротиворечивый инструментарий для работы с данными.
С этого момента разработчики , естественно, предпочитали строить механизмы СУБД на основе хорошего математического аппарата. Другое дело, что со временем в программистскую индустрию пришли люди без серьезной математической подготовки.
И в "реляционные" СУБД начали вносить "улучшения", которые не укладывались в математический аппарат, приводили к неоднозначности и т.д.
| № 275 04-10-2009 15:12 | |
Ответ на »сообщение 270« (Cepгей Poщин)
___________________________
>>> Во имя каких таких высоких целей требуется идти на такие жертвы?
Во имя Прогресса!
| № 274 04-10-2009 15:11 | |
| № 273 04-10-2009 14:41 | |
Ответ на »сообщение 272« (Сергей Перовский)
___________________________
Этот подход позволяет строить базу для ERP систем не из тысяч таблиц, а из 20 - 30 таблиц, в которых просто ориентироваться. Зато появляется большое количество самопальных атрибутов, типов и т.п., в которых тоже надо както ориентироваться.
Я понимаю, есть определенный круг задач, когда это неоходимо, мало ли какие анкетные данные потребуются (национальность, цвет глаз, обём бёдер :) Но распространять такой стиль на любые БД — это перебор.
| № 272 04-10-2009 13:57 | |
Ответ на »сообщение 264« (Антон Григорьев)
___________________________
А можно с этого места поподробнее? Это что - для каждого возможного атрибута отдельная таблица?
Нет, для всех дополнительных атрибутов одна таблица с полями КОД ОБЪЕКТА, КОД АТРИБУТА, ТИП АТРИБУТА, ЗНАЧЕНИЕ АТРИБУТА.
Причем все поля целочисленные :)
Дело в том, что это рабочая таблица для алгоритмов поиска и иной обработки. Она не предназначена для прямой визуализации.
Для имен и некоторых типов потребуются справочники. Первоначально, поле КОД АТРИБУТА называлось ЕДИНИЦЫ ИЗМЕРЕНИЯ.
Но с появлением строковых атрибутов пришлось расширить его назначение - это код процедуры, которая будет приводить внутреннее представление данных к отображаемому на экране.
Зачем такие страсти? Этот подход применяется в случае, когда рост числа атрибутов в процессе работы неизбежен и интенсивен. Переструктурировать базу каждый раз просто невозможно.
Тут можно провести аналогию с наследованием в ООП. Таблица заводится под базовый тип и ЛЮБЫЕ его расширения. Понятно, что в ней могут быть только поля базового типа. А все поля наследников в дополнительную таблицу.
Этот подход позволяет строить базу для ERP систем не из тысяч таблиц, а из 20 - 30 таблиц, в которых просто ориентироваться.
| № 271 04-10-2009 11:36 | |
Ответ на »сообщение 270« (Cepгей Poщин)
___________________________
>>> по сути предлагается сделать то же самое, но самому
... если этого пока не сделали разработчики в той или иной СУБД.
>>> Есть так же различные инструменты упрощающие жизнь администратору/архитектору БД, их тоже на помойку
И разработать новые инструменты, более полные.
>>> Во имя каких таких высоких целей требуется идти на такие жертвы?
Я над такого рода структурой задумывался для проектирования системы, в которой пользователь можен сам добавлять дополнительные атрибуту к сущностям. Не переделывать же каждый раз структуру БД (как это иногда пытаются делать начинающие разработчики баз данных, выходящие потом с вопросами на КС). А штука очень удобная. Разработчик (даже если он семи пядей во лбу) в жизни не сможет предусмотреть всех атрибутов, которые смогут потребоваться пользователю. А если все же сможет и честно заложит в структуру таблиц поля под каждый атрибут, то таблицы будут на 99% состоять из воздуха.
Второй вариант -- системы конструкторы. Естественно, не те, которые используют принцип 1С (типа, нужно новое понятие, введем новую таблицу). Использование такого рода конструкций позволяет очень просто расширять возможности Системы.
<<<... | 280—271 | 270—261 | ...>>>
Всего сообщений в теме: 290; страниц: 29; текущая страница: 2
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
|
