|
GaryaВсе меняется... (не помню, кто сказал). Если бы я жил НЕ в России, где все меняется в режиме быстрой перемотки, то, может быть, мое мнение по этому вопросы было менее категоричнымНе очень понятна ссылка на Россию. Древние восточные философы говорили: “Все – есть перемены”. Но как перемены связаны с темой?
GaryaВ свое время мне пришлось решать такую проблему. Изменились НАШИ банковские реквизиты (я уже не говорю о чужих). Нужно сделать так, чтобы старые документы распечатывались со старыми реквизитами, а новые - с новымиИ в чем проблема? По всей видимости в ошибке проектирования. Но эта ошибка легко поправима: надо добавить к таблице поле (ALTER TABLE ADD...), где у старой записи сохранить ссылку на новую запись. Обе записи стали полноправны, для старых документов будет актуальна старая запись, для новых – новая.
GaryaКогда кто-то из сотрудников меняет фамилию или имя, то меня, как "асунизатора", вообще не должно волнововать, по какой причине это произошло. Вышел ли кто-то замуж, или ему опостылело имя "Канализация", которое родители дали, посчитав, что оно красиво звучит (кстати, вполне реальный случай). Для организации, где я работаю, важно, что это один и тот же человек. ПОЧЕМУ мы считаем Настью и Канализацию одним и тем же человеком - это не должно интересовать информационную систему. Эта наша, человеческая область. Если мы посчитаем, что это разные сущности, мы введем их дважды, даже если у них одинаковый номер паспорта. Может быть, мы ХОТИМ видеть одного и того же человека, как двух разных. Это не КИСкино дело! Имхо, конечноС чего Вы решили, что любые атрибуты могут выступать в качестве первичного ключа? Для однозначной идентификации сотрудника организации существует “Табельный номер”. Наверное, надо было познакомиться с предметной областью более глубоко, прежде, чем браться за автоматизацию.
Garya ASUС первой стороны, первичный ключ - это уникальная метка. И нет никакой разницы является ли эта метка внутренней или внешней. Со второй стороны, первичный ключ - это элемент взаимосвязи между сущностями. И порой, лишая смысла первичный ключ, мы лишаем смысла и связи, в которых принимает участие данная сущностьОчень правильные слова! Если мы используем СК, то мы вольны придавать смысл сущности тот, который пожелаем. Когда мы используем ЕК, то у нас уже нет такой свободыН-да... А как же быть с предметной областью? В ней уже дан смысл каждой сущности, в противном случае, этих сущностей просто бы не существовало. С таким подходом к проектированию, придется и предметную область свою придумывать и ее... пользователей.
GaryaЕсть искусствено притянутые за уши ограничения, который, возможно, оправдываются в большинстве ситуаций, но достаточно одной нестандартной ситуации, чтобы оказаться в полному тупике, выяснив, что ЕК совскем не такой уж "естественный", как казалось раньшеМожно пример.
Garya ASUВполне достаточно координат
Увы, не достаточно. Один введет координаты мавзолея Ленина на Красной площади, другой - геометрического центра Москвы (который по мере ее застройки постоянно перемещается)Координаты в терминах долготы и широты образуют уникальное значение для любого предмета на поверхности Земли. Если предметная область требует еще и вертикальной координаты, то ее надо ввести на этапе проектирования.
GaryaИ они окажутся разными. А для ключа это недопустимоНе выдумывайте, пожалуйста.
GaryaКроме того, использование координат с точки зрения соответствия практическим манипулированием информацией НЕЕСТЕСТВЕННО . Эту информацию пользователю-колотильщику по клавиатуре НЕГДЕ ВЗЯТЬ. Конечно, можно заставить вместо наименований населенных пунктов вводить коды ОКАТО. Но пока они научатся в них ориентироваться... И потом, для меня был как гром среди ясного неба, когда я узнал, что для целых регионов в России с некоторого времени коды ОКАТО изменились
И что страшного произошло? Изменились, ну, и что? Два населенных пункта стали иметь один и тот же код?
Garya ASUЕсли на этапе проектирования нет представления о том, для какого уровня создается система, то здесь никакой суррогатный ключ не спасет...Вопрос спорный, определяется степенью предсказуемости изменений. Нас интересует НАСЕЛЕННЫЙ ПУНКТ , в котором находится контрагент, и АРЕАЛ, где он находится. Под словом "АРЕАЛ" можно понимать вещи совершенно разные для разных видов анализа. И заранее трудно сказать, что под ним будет подразумеватьсяНаверное, в этом и проблема - не изученность предметной области. В таком случае невозможно отвечать за достоверность информации в базе данных.
GaryaЕсли мы обозначим населенный пункт ТОЛЬКО наименованием, то попадем в тупик, когда узнаем, что Москва есть еще и в Америке, с поставщиком из которой мы стали работать недавно. Если мы в качестве уточняющей информации добавим понятие "Страна", то попадем в тупик, узнав, что в России Москва далеко не единственная. Какой выход? Создается суррогатный ключ и поле "примечание". Вот в примечании мы и напишем, чем эта Москва отличается от двух остальных, если нам не хватает базовых полей для описания отличий этих сущностей. И наша система будет нормально фунциклировать с треми Москвами, и выдаст корректно информацию о деятельности по странам, когда мы ее запросим. И даже по регионам России, если она естьВы говорите о проблеме изучения предметной области? Или о том, как свои проблемы перекладывать на плечи пользователей? GaryaДалее, встает традиционный ворпос о длине ключа. Для того, чтобы ЕСТЕСТВЕННЫЙ ключ сделать гарантированно уникально описывающим сущность, в идеале в него приходится включать практически все поля-атрибуты сущности (разве не так?). О какой эффективности тут можно говорить, о какой нормализации?Хм... Вы что-то знаете о нормализации? Сомневаюсь. Нормализация не имеет отношения к вопросу выбора ключа по той простой причине, что нормализация проводится после того, как ключ выбран (определены функциональные зависимости, найдены детерминанты и выбран ключи из потенциальных ключей).
Вопрос о длине ключа является надуманным. Естественный ключ может быть больше или меньше суррогатного ключа. Например, для стран и валют есть принятые международным сообществом аббревиатуры размером в 2-3 символа. Суррогатный ключ будет иметь размер принятый в данной СУБД (4-8 байт).
В задачи ключа не входит экономить место, его задача однозначно идентифицировать кортеж.
Garya авторМожно, например, пользуясь суррогатным ключем завести 100 раз один и тот же город? Можно. Можно завести два разных города по одним и тем же координатам? Можно. Так чем же помогает суррогатный ключ?
Имхо, не следует смешивать логику проверки на допустимость операции с логикой отношения между объектамиЧего? Простите, но что такое “допустимость операций”?
GaryaЕсли действительно существуют 100 городо в с одним и тем же наименованиемПростите, но я говорил не о множестве городов с одним именем, а о том, что один и тот же город заводят в БД много раз. Разницу понимаете?
GaryaА что делать, когда ты использовал поле "Name" в качестве ЕК, а через 2 года эксплуатации выяснилось, что нужно ввести записи с повторяющимся значением поля "Name"?Если я использую в качестве ключа набор атрибутов не обеспечивающий уникальности, то мне придется признать, что я напрасно ем хлеб проектировщика БД. Но за всю мою жизнь, ни разу такого не случалось (проектированием БД я занимаюсь порядка 20 лет).
GaryaКроме того, ЕК сам по себе не спасает от дублирования информации (знаю это по богатому опыту)Он так же не спасает ни от лени, ни от глупости, ни от головной боли. А разве должен?
|
