Что такое суррогатный ключ

В чем разница между первичным ключом и суррогатным ключом?

Я много гугл, но я не нашел точного прямого ответа с примером.

Любой пример для этого был бы более полезным.

Первичный ключ – это уникальный ключ в вашей таблице, который вы выбираете, который наилучшим образом идентифицирует запись в таблице. Все таблицы должны иметь первичный ключ, потому что, если вам когда-либо понадобится обновить или удалить запись, вам нужно знать, как ее однозначно идентифицировать.

Суррогатный ключ – это искусственно созданный ключ. Они полезны, когда ваши записи по существу не имеют естественного ключа (например, таблицы Person , так как возможно, что два человека, родившиеся в одну дату, имеют одно и то же имя или записи в журнале, поскольку это возможно для двух событий чтобы они были такими, они несут одну и ту же метку времени). Чаще всего вы увидите, что они реализованы как целые числа в автоматически увеличивающемся поле или как GUID, которые автоматически генерируются для каждой записи. Идентификационные номера – это почти всегда суррогатные ключи.

В отличие от первичных ключей, не все таблицы нуждаются в суррогатных ключах. Если у вас есть таблица, в которой перечислены состояния в Америке, вам не нужен идентификационный номер для них. Вы можете использовать аббревиатуру состояния как первичный key code.

Основным преимуществом суррогатного ключа является то, что их легко гарантировать как уникальное. Основной недостаток заключается в том, что они не имеют никакого значения. Там нет смысла, что, например, “28” – это Висконсин, но когда вы видите “WI” в столбце “Состояние” вашей таблицы “Адрес”, вы знаете, в каком состоянии вы говорите, не задумываясь о том, какое состояние находится в вашем государстве таблица.

A суррогатный ключ – это сделанное значение с единственной целью уникальной идентификации строки. Обычно это обозначается идентификатором автоматического увеличения.

A первичный ключ – это столбец идентификации или набор столбцов таблицы. Может быть суррогатным ключом или любой другой уникальной комбинацией столбцов (например, составной ключ). Должен быть уникальным для любой строки и не может быть NULL .

Все ключи – это идентификаторы, используемые в качестве суррогатов для того, что они идентифицируют. E.F.Codd объяснил концепцию присваиваемых системой суррогатов следующим образом [1]:

Пользователи базы данных могут заставить систему генерировать или удалять суррогат, но они не имеют никакого контроля над своей ценностью, равно как и ее ценность никогда отображается на них.

Это то, что обычно называют суррогатным ключом. Это определение сразу же проблематично, поскольку Codd предполагал, что такая функция будет предоставлена ​​СУБД. СУБД вообще не имеют такой возможности. Клавиши обычно видны, по крайней мере, некоторым пользователям СУБД, поскольку по очевидным причинам они должны быть. Поэтому понятие суррогата слегка изменилось в использовании. Этот термин обычно используется в профессии управления данными для обозначения ключа, который не отображается и используется как идентификатор в бизнес-домене. Обратите внимание, что это по существу не связано с тем, как генерируется ключ или как “искусственно” он воспринимается. Все ключи состоят из символов, изобретенных людьми или машинами. Таким образом, единственное возможное значение термина “суррогат” относится к тому, как используется ключ, а не как он создан или каковы его значения.

[1] Расширение реляционной модели базы данных для большей значимости, E.F.Codd, 1979

Это отличное лечение, описывающее различные типы ключей:

Суррогатный ключ обычно представляет собой числовое значение. В SQL Server Microsoft позволяет определить столбец с идентификационным свойством, чтобы помочь генерировать суррогатные значения ключа.

Ограничение PRIMARY KEY однозначно идентифицирует каждую запись в таблице базы данных.
Первичные ключи должны содержать УНИКАЛЬНЫЕ значения.
Столбец первичного ключа не может содержать значения NULL.
Большинство таблиц должны иметь первичный ключ, и каждая таблица может иметь только один первичный ключ.

Я думаю, что Мишель Пулет описывает это очень четко:

Суррогатный ключ – искусственно созданная ценность, чаще всего управляемый системой, увеличивающий счетчик, значения которого могут варьироваться от 1 до n, где n представляет таблицу максимального количества строк. В SQL Server, вы создаете суррогатный ключ, назначая свойство идентификации столбец с типом данных.

Обычно вы можете использовать суррогатный ключ при изменении составного ключа с помощью столбца идентификации.

Естественные и суррогатные ключи

Реляционной базой данных называют совокупность взаимосвязанных таблиц, каждая из которых задаёт некоторое отношение. Реляционная база данных имеет уникальное имя, по которому к ней можно обращаться.

Таблицы. Как мы уже говорили, это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).

Каждая таблица реляционной базы данных также имеет имя.

Столбцы таблицы должны иметь только атомарные значения. Например, показатель, отображающий год рождения, является атомарным и может быть столбцом таблицы. Показатель «адрес» не может быть столбцом. Он состоит и нескольких частей: город, улица, дом, квартира.

Ширина столбцов должна быть фиксированной. Каждый столбец имеет имя, тип, допустимое множество значений, ширину. Указанные атрибуты называются спецификация столбца.

Для обращения к столбцам можно использовать квалифицированное имя, т.е. имя, состоящее из имени соответствующей таблицы и собственного имени столбца. Имена таблицы и столбца соединяются точкой: .

Столбцы таблиц базы данных, при изложении теории, называются доменами, а в практике использования называются полями, а иногда атрибутами. В таблице не должно быть повторяющихся строк.

Обычно строки называют записями.

Столбец (поле), все значения которого не могут повторяться, может быть объявлен автором базы данных первичным ключом.

Первичный ключ служит для доступа к строкам таблицы. Первичный ключ может быть составным. Если кандидата на ключ в таблице нет, то вводится искусственно специальный числовой ключ — счётчик.

Ключ позволяет поддерживать связи между таблицами.

Для этого некоторые из ключевых полей разных таблиц отождествляются. Установленные тождества определяют связи (отношения) между таблицами базы данных.

Установление связи между таблицами возможно только при следующих условиях:

§ связываемые поля должны иметь один и тот же тип, причём имена полей могут быть различны;

§ обе таблицы принадлежат одной и той же базе данных;

§ связь между таблицами устанавливается по ключевому полю.

Явное указание связей помогает исключить возможные ошибки, которые могут возникнуть в процессе корректировки базы данных. Для этого вводится ряд условий, которым должны удовлетворять записи таблиц базы данных. Совокупность этих условий называют условиями целостности базы данных. Для формулировки условий целостности введём следующую терминологию. Таблицы, в которых описываются объекты предметной области, назовём главными, а таблицы, описывающие связи между объектами, назовём таблицами связи.

Первичные ключи главной таблицы называются внутренними, а соответствующий ключ в таблице связи называется внешний ключ.

Обеспечение целостности базы данных достигается с помощью выполнения следующих требований:

§ в таблицу связи не может быть добавлена запись с несуществующим в главной таблице значением первичного

§ в главной таблице нельзя удалить запись, если не удалены связанные с ней записи в таблице связи;

§ изменение значения первичного ключа в главной таблице должно приводить к изменению соответствующих значений в таблице связи.

Первичный ключ может состоять из информационных полей таблицы (то есть полей, содержащих полезную информацию об описываемых объектах). Такой первичный ключ называют естественным ключом. Теоретически, естественный ключ всегда можно сформировать, в этом случае мы получим т. н. интеллектуальный ключ. На практике, однако, использование естественных ключей наталкивается на определённые сложности:

Низкая эффективность — Естественный ключ может быть велик по размеру (особенно когда он составной), и его использование окажется технически неэффективным (ведь во всех таблицах, связанных с данной, понадобится создать поле того же размера, чтобы хранить ссылки).

§ Необходимость каскадных изменений — При изменении значения поля, входящего в естественный ключ, оказывается необходимым изменить значение поля не только в данной таблице, но и во всех таблицах, связанных с данной, в противном случае все ссылки на данную запись окажутся некорректными. В сложных базах данных таких связанных таблиц может быть очень много, и всегда остаётся опасность упустить из виду какую-то из них. При добавлении новых связанных таблиц приходится добавлять согласующие изменения во все места программ, где правится исходная таблица.

§ Несоответствие реальности — Уникальность естественного первичного ключа в реальных БД не всегда соблюдается. Допустим, например, что первичный ключ в таблице — данные личного документа. В такую таблицу окажется невозможным внести человека, о документах которого нет информации в момент добавления записи, а на практике такая необходимость может возникнуть.

§ Повторяемость — При использовании естественного ключа, содержание может повторяться (так, как могут повторятся поля, из которых состоит ключ), что недопустимо в первичном ключе

Вследствие этих и других соображений в практике проектирования БД чаще используют т.н. синтетические (суррогатные) ключи — искусственно созданные технические ключевые поля, не несущие информации об объектах.

Вне́шний ключ (англ. foreign key) — понятие теории реляционных баз данных. Внешним ключом называется поле таблицы, предназначенное для хранения значения первичного ключа другой таблицы с целью организации связи между этими таблицами.

Пусть имеются таблицы A и B. Таблица A содержит поля a, b, c, d, из которых поле a — первичный ключ. Таблица B содержит поля x, y, z. В поле y содержатся значение поля a одной из записей таблицы A. В таком случае поле y и называется внешним ключом таблицы A в таблице B.

Вот такой SQL-запрос вернёт все связанные пары записей из таблиц A и B:

select * from A, B where A.a = B.y;

Внешний ключ в таблице может ссылаться и на саму эту таблицу. В таких случаях говорят о рекурсивном внешнем ключе. Рекурсивные внешние ключи используются для хранения гомогенной древовидной структуры данных в реляционной таблице.

Развитые СУБД поддерживают автоматический контроль ссылочной целостности на внешних ключах.

Задача разработчика реляционной базы данных состоит в структуризации данных, чтобы обеспечить быстрый поиск нужной информации и исключить ненужное дублирование данных. Процесс разделения базы данных на структурные единицы — таблицы для достижения этих целей называется нормализацией. Нормализация достаточно сложный процесс. Правила нормализации описаны в ряде руководств по проектированию реляционных баз данных и им придаётся большое значение. Однако существует альтернативный, более простой способ нормализации базы данных. Он годится во всех простых случаях. Этот способ заключается в том, что сначала создаются таблицы для всех объектов предметной области. Затем определяются таблицы для связей между объектами. Если существуют поля, в которых много повторяющихся значений, целесообразно создать справочник.

Первичный ключ, внешний ключ, суррогатный ключ ⁠ ⁠

Первичный ключ – это столбец (или набор столбцов) в таблице, с помощью значения которого (которых) всегда можно сослаться, выйти только на одну строку в таблице. Значения этого столбца служат идентификатором каждой строки таблицы и поэтому не могут иметь пустые или повторяющиеся значение. Если в таблице данных нет столбца с данными, которые могли бы быть уникальны в пределах таблицы (а такой столбец нужен), то добавляется ещё один столбец к таблице, данные которого не имеют отношения к смыслу хранящихся сведений и почти всегда являются просто сквозной авто-нумерацией строк. Этот столбец и называется суррогатным ключом.

Если в таблице данных нет столбца с данными, которые могли бы быть уникальны в пределах таблицы (а такой столбец нужен), то добавляется ещё один столбец к таблице, данные которого не имеют отношения к смыслу хранящихся сведений и почти всегда являются просто сквозной авто-нумерацией строк. Этот столбец и называется суррогатным ключом.

1. Если у тебя в таблице нет уникального сочетания полей – ты долбоёб, иди читай про нормализацию БД.

2. Суррогатный ключ используют в качестве первичного тогда, когда уникальность обеспечивают плохо индексируемые данные. Ну, например, “Свидетельство о рождении”. Номер – уникальный, но так-то это строка. Искать по строке – плохо, по числу – гораздо быстрее. Или сочетание нескольких полей.

И снова про обучение в IT⁠ ⁠

Пост будет короткий и несёт чисто информационный характер.

Как вы можете видеть по моим постам, я помогаю всем желающим выучить SQL и «войти в айти»

Многим на Пикабу не нравится формат телеграм каналов/чатов.

Поэтому учебный план я перенёс с telegrap на GitHub pages.

Вся информация на сайте актуальная и переодически обновляется.

Проект полностью некоммерческий.

Когда я выполняю DELETE запрос и понимаю, что забыл дописать WHERE. ⁠ ⁠

Когда я выполняю DELETE запрос и понимаю, что забыл дописать WHERE.

Из курса mysql для чайников⁠ ⁠

Из курса mysql для чайников IT юмор, SQL, База данных, Запросы, Повтор

Базы данных – почему бизнес их боится / избегает⁠ ⁠

Базы данных - почему бизнес их боится / избегает IT, Цифровые технологии, Технологии, Microsoft Excel, База данных, Данные, Анализ данных, Большие данные, Утечка данных, Хранение данных, Прогресс, SQL, Postgresql, Postgres

Раньше странно было наблюдать, почему при автоматизации бизнес процессов заказчики боятся баз данных

Цепляние за эксель у многих происходит до последнего

Вроде бы уже все, можно отпустить и двигаться дальше. Но нет. Давайте лучше эксель

Эксель для них это последний бастион, где они еще удерживают ситуацию под контролем. Можно залезть ручками в файл, настроить фильтры, поковыряться. Если надо, то что-то подправить в формулах и связях между таблицами

Читайте также:  Что такое зависимое расстройство личности

Переход к базе данных это следующий уровень сложности, знаний для контроля над которым просто нет

Тут они уже нутром понимают, что обратной дороги не будет. Придётся зависеть от этих мутных ИТ-шников, с их sql запросами и прочей магией

В экселе – все понятно, вот файл, в нем закладки с табличками

А база данных это где?

Еще хорошо если на локальном сервере. По крайне мере может покажут стационарный комп с мигающими лампочками. В мозгах может появится успокаивающая ассоциация, что этот ящик и есть база данных. Тогда его можно в охраняемую комнату запереть и спать спокойно.

А если база данных в “облаке”?

В газетах вон постоянно пишут про хакеров и как из облаков данные утекают

Тут все надежно, проверено мудростью предков, и есть панацея от всех проблем: ctrl+alt+delete

Когда для тебя SQL это не просто буквы⁠ ⁠

Когда для тебя SQL это не просто буквы

О печальной защите информации в 2017 году⁠ ⁠

В данном посте я хочу поговорить не про гигантов типа Google, Яндекс или ВК, а про обычные компании с которыми мы работаем или которые не так известны.

Несмотря на кучу законов типа ФЗ-152 уровень защищенности персональных (и не только) данных к сожалению переживает по моим наблюдениям не лучшие свои времена.

К сожалению утечки встречаются почти на каждом шагу, большинство по работе. Я хочу рассказать о найденных мной уязвимостях в 2017 году.

В начале этого года попросили проверить одну Windows программу с целью узнать, что она вообще делает. Программа позиционировала себя как обратная связь клиента с фирмой, своеобразный такой чат.

Вооружившись VirtualBox с установленным внутри WireShark и другими средствами мониторинга начал следить за программой, исследовал формочки приложения. В WireShark промелькнул HTTP-запрос, отправляющий сообщение на сервер. Так же обнаружил и HTTP-запрос, получающий сообщения с сервера. Немного поразбежавшись, обнаруживаем, что никакой авторизации на стороне сервера нет. Получаем сразу 2 уязвимости. Мы можем читать сообщения любого пользователя, включая, что пишут админу, а так же от имени пользователя отправлять сообщения другому пользователю.

На следующую уязвимость в конце зимы или весной в 2017 году я наткнулся совершенно случайно с помощью рекламы в Яндекс-Директе.

Попалась на глаза мне контекстная реклама одной фирмы, которая говорила, что есть филиалы во многих городах РФ. Что-то тогда меня заинтересовало и я открыл их сайт.

Там открыл форму обратной связи.

С удивлением замечаю попадаю на сайт без домена, а только IP-адрес сервера.

Стало любопытно, а что работает на этой машинке? Проверяю порт FTP и… захожу под гостем. Куча всяких файлов, рабочая WEB-папка со страницами сайта. Есть немножко бэкапов. С виду сервер использовался как или помойка или как тестовый сервер.

Открываем файл конфигурации из Web-папки … Видим логин и пароль от FTP-другого сервера.

Проверяем… И попадаем уже во второй сервер…

Там тоже поднят WEB-сервер и вообще файлов намного больше… на 200 гигабайт с лишним. В основном это конечно бэкапы баз, но и очень много рабочих и свежих документов.

Внутри конфига WEB-сервера уже засвечивается и SQL-сервер с логином и паролем, который крутится на этом сервере. И да. На него тоже можно попасть.

Итог: получаем утечку в из крупной фирмы с возможностью исказить/уничтожить информацию и бэкапы баз данных.

Также в этом году для работы потребовалось создать парсер сайта довольно большой бюджетной организации для формирования БД (около миллиона строк в 3 таблицах), что бы уменьшить ручной труд и постоянные запросы к сайту. Сам сайт тоже тот еще тормоз, поэтому создание парсера было логичным решением, что бы получить сразу готовые таблицы и всегда иметь их под рукой.

В голове вместе с алгоритмом парсера и количество срок кода росла также лень всё это делать. Тогда я решил проверить теорию с предыдущим сервером. И.. Вы не поверите! Ситуация практически повторилась! Мы опять попали на FTP сервер, но на этот раз там лежал файл VPNRouter_64.vmdk. Виртуальная машинка.

Немного колдуем над файлом и получаем доступ к разделу виртуального диска внутри машинки.

Самое интересное, это папка OpenVPN с настроенной конфигурацией и сертификатами.

Копируем на свой комп, подключаемся, и… Бинго! Мы внутри защищенной сети.

Смотрим какой нам присвоил сервер виртуальный IP.

Открываем терминал, запускаем nmap сканируем всю подсеть на 80,21,1433 порты.

Есть несколько компьютеров с такими открытыми портами!

И опять нас радостно встречает FTP без пароля на одном из серверов!

А дальше классика. Открываем Web.config, получаем строку подключения к серверу и с помощью dBeaver мы получаем доступ к базе данных внутри сети. Что еще интереснее, данная комбинация подошла и на другие SQL-сервера внутри этой сети. Один пароль на все сервера (всего их было 3-5 серверов, уже не помню). И это довольно крупная бюджетная организация для нашего региона!

Опять же возможность положить сайты, совершить утечку персональных данных (я там себя нашёл), исказить/удалить.

Сами персональные данные мне уже не интересны. Я с ними работаю каждый день, допуск к базе своего региона (ну или большей её части) у меня есть и так.

Еще один случай опять же на работе, опять же в этом году.

Другая бюджетная организация дала VPN (L2TP) доступ и программку которая работает с их сервером, обмен с базой данных.

В таком режиме мы уже работаем давно, но программист написавший программу уже уволился, а неудобства с программой проявляются все сильнее и мысли написать свою программу типа плагина или хотя бы нужные скрипты. И тогда я решил провести один эксперимент, а именно попробовать подключиться не через их прогу, а через редактор БД. Выдергиваю, по какому адресу их программа стучится, вбиваю в редактор БД, и… сервер нас впустил! Ему хватило подключения по VPN и доверительное соединение! Мы опять получаем доступ к серверу ко всем базам, которые там находятся со всеми вытекающими, куда по идее мы не должны были попасть.

Похожая ситуация и в самой корпоративной сети, опять же в этом году.

Дали программу, файл реестра, внутри которого… Логин sa, пароль 111111As…. Доступ из внешки… Ну хоть не на стандартном порту. А на нем так же крутиться персональная информация! Любой админ из корпоративной сети сути может увидеть инфу другого филиала через SQL-редактор, к которой он не должен иметь доступа, а так же изменить/удалить всю БД! А то что изначально дали доступ без защищенного канала еще хуже! Благо щас перевели программу на Vipnet, но пару месяцев назад доступ по внешнему IP еще был, может и до сих пор есть.

Недавно проводил исследование одного Android-приложения (мой предыдущий пост), там такая же плачевная ситуация. Любой школьник может получить доступ к информации без авторизации, слить бюджет на СМС, зафлудить СМС чей нибудь телефон, исказить рейтинг, слить базу данных. Так же существует возможность получить права баристы простым брутом пароля!

Это всё печально дамы и господа. Давайте, мы будем относиться к защите наших серверов/ПК/телефонов более серьезно. Для проникновения внутрь не понадобились никакие эксплоиты, хакерские навыки. Только штатные программы и любознательность.

А сколько подобных серверов с открытым доступом в интернете? А сколько еще таких дырявых приложений в Маркете? Наверно тысячи, десятки тысяч.

Вполне возможно, Вы так же сталкивались с похожими ситуациями, надеюсь без злых намерений.

Многие этим профессионально занимаются, пишут ботов которые ползают по интернету, пробивают стандартные порты, брутят по словарю, ломают роутеры, IP-камеры, увеличивая армию ботов. С такими ботами встречался и я, точнее мой Firewall и было занятно наблюдать как пытались подобрать пароль от моей базы по примерно по 5-10 запросов в секунду.

Так же попадались боты которые пытались ломануть мой FTP и VNC сервер из разных стран.

Обнаружив эти попытки в логах, я убрал компы за NAT и с тех пор я держу все порты закрытыми, оставив только порт для VPN-соединения, а при, необходимости временно доступа другим людям, открываю временно их на нестандартных портах. Для постоянно доступа использую OpenVPN и генерирую сертификаты на каждое устройство.

Итак. Для минимальной безопасности:

1. Не держите FTP сервер с возможностью подключаться анонимусом. Не держите на FTP какую либо инфу, позволяющая скомпрометировать другие сервера. Конечно, если это Web-сервер и через FTP обновляется его содержимое, то дайте ему минимальные права, если его вдруг вскроют.

2. Не используйте простые пароли, которые можно легко сбрутить. Поверьте, боты не спят и рано или поздно могут приняться за ваш сервер, если он виден извне.

3. Используйте защищенное соединение. Если это не предоставляется возможным, вешайте службы на нестандартные порты. Такие порты найти сложнее и сканировать один комп относительно долго. Если есть настроенный Firewall, то вполне может сработать тревога сканирования портов и при их прозвоне ботом, фаервол начнет посылать все попытки подключения бота в лес, а порты ботом так и не будут найдены.

4. Если возможно, старайтесь в Андроид-приложениях шифровать все HTTP-запросы. Например http://127.0.0.1/web?query=vcXGregfds4r5f3r456sdr32vdf-6t и ответ получать примерно такой же. Через снифер уже не будет видна какая-либо зависимость от запросов и большинство любителей это уже может остановить. В идеале еще прикрутить защищенное соединение, но многих останавливает, что SSL-сертификаты платные. Можно еще использовать сокеты.

5. Не оставляйте в приложениях права админа, например в веб-приложениях, десктопных. Старайтесь давать минимальные права приложениям. Фукнции авторизации желательно вешать на сервер, а дальше посылать только ID-сессии, а не UserID. При обмене данными всегда проверять авторизована ли машина или нет. Особенно это касается Web- и Android-приложении.

6. Периодически проверяйте логи приложений, а так же лог фаервола.

7. Сервера желательно прятать за NAT, а в некоторых случаях (например, если это сервер с персональными данными или где проводятся финансовые операции) за двойной NAT.

8. Ну про своевременную установку патчей и обновлений, я думаю не стоит объяснять.

9. Ну и конечно следите за новостями о вирусных угрозах, эпидемиях, новых шифровальщиках

Желаю всем в следующем году стабильных линков, отсутствие зловредов и хороших клиентов. Сделаем наши сервера, базы данных и приложения более защищенными.

Вопрос о дизайне реляционной базы данных – суррогатный ключ или естественный ключ?

Какой из них является наилучшим и почему?

а) Таблица типов, суррогатный / искусственный ключ

alt text

Внешний ключ от user.type в type.id :

б) Таблица типов, естественный ключ

alt text

Внешний ключ от user.type в type.typeName :

задан 19 сен ’10, 19:09

Спасибо за ясный и красивый вопрос. Я использовал это на ‘Introducció a les base de dades’ упражнения с ваша атрибуция. – dani herrera

10 ответы

Я считаю, что на практике, используя естественный ключ редко бывает лучшим вариантом. Я бы, наверное, пошел на суррогатный ключ подход, как в вашем первом примере.

Ниже перечислены основные недостатки подхода с естественным ключом:

Возможно, у вас неправильное имя типа, или вы можете просто переименовать тип. Чтобы отредактировать его, вам нужно будет обновить все таблицы, которые будут использовать его в качестве внешнего ключа.

Указатель на int поле будет намного компактнее, чем поле на varchar поле.

В некоторых случаях бывает трудно иметь уникальный естественный ключ, и это необходимо, поскольку он будет использоваться в качестве первичного ключа. Это может не относиться к вашему случаю.

спасибо за подробный ответ, другие ответы тоже были отличными – арьякст

Как правило, лучшим решением является и то, и другое: иметь суррогатный ключ для ссылочной целостности и естественный ключ (как правило, составной) для обеспечения уникальности кортежа. Итак, в приведенном выше примере уникальное ограничение / индекс будет существовать для type.typename и для некоторой комбинации столбцов в user. – Адам Муш

Первый вариант является более перспективным, поскольку он позволяет изменять строку, представляющую тип, без обновления всей пользовательской таблицы. Другими словами, вы используете суррогатный ключ, дополнительный неизменяемый идентификатор, введенный для гибкости.

Хорошая причина использовать суррогатный ключ (вместо естественного ключа, такого как имя), – это когда естественный ключ на самом деле не является хорошим выбором с точки зрения уникальности. За свою жизнь я знал не менее четырех «Крисов Смита». Имена людей не уникальны.

Я предпочитаю использовать суррогатный ключ. Часто люди идентифицируют и используют естественный ключ, что будет нормально какое-то время, пока они не решат, что хотят изменить значение. Потом начинаются проблемы.

в базах данных, которые должным образом поддерживают семантику внешнего ключа, изменить это сложно только с точки зрения получения правильной схемы (каскады обновления в нужных местах). Если ваша база данных не поддерживает это, то вы правы, избегая естественных ключей. – SingleNegationElimination

Вероятно, вам всегда следует использовать идентификационный номер (таким образом, если вы измените имя типа, вам не нужно обновлять таблицу пользователей), это также позволяет вам уменьшить размер данных, поскольку таблица, полная INT, намного меньше единицы полный 45 символов varchars.

Читайте также:  Что такое забрус медовый

Если typeName является естественным ключом, то это, вероятно, предпочтительный вариант, поскольку для получения значения не требуется соединение.

Вам следует использовать суррогатный ключ (id) только тогда, когда имя может измениться.

Суррогатный ключ и для меня, пожалуйста.

Другой может быть проще, когда вам нужно взломать какой-то код, но в конечном итоге это будет сложнее. В свое время мой технический босс решил, что использование адреса электронной почты в качестве первичного ключа было хорошей идеей. Излишне говорить, что когда люди хотели сменить адрес, это было ужасно.

Используйте естественные ключи, когда они работают. Имена обычно не работают. Они слишком изменчивы.

Если вы изобретаете свои собственные данные, вы также можете изобрести синтетический ключ. Если вы создаете базу данных данных, предоставленных другими людьми или их программным обеспечением, проанализируйте исходные данные, чтобы увидеть, как они идентифицируют вещи, требующие идентификации.

Если они вообще хорошо управляют данными, у них будут естественные ключи, которые работают для важных вещей. Для неважных делайте сами.

ну, я думаю, что суррготный ключ полезен, когда у вас нет какого-либо однозначно идентифицированного ключа, значение которого связано и значимо, как его первичный ключ . более того, суррготный ключ легче реализовать и меньше накладных расходов на обслуживание.

но, с другой стороны, суррготный ключ иногда требует дополнительных затрат за счет объединения таблиц. подумайте о “Пользователе” . У меня есть

как структура таблицы.

теперь учтите, что я хочу отслеживать во многих таблицах, кто вставляет записи . если я использую Id в качестве первичного ключа, тогда [1,2,3,4,5..] и т.д. будут в сторонних таблицах, и всякий раз, когда мне нужно знать, кто вставляет данные, я должен присоединиться к таблице пользователей, потому что 1,2,3,4,5,6 бессмысленно. но если я использую UserId как первичный ключ, который однозначно идентифицируется тогда в других сторонних таблицах [john, annie, nadia, linda123] и т.д., которые иногда легко различимы и значимы. поэтому мне не нужно присоединяться к пользовательской таблице каждый раз, когда я делаю запрос.

но имейте в виду, что требуется дополнительное физическое пространство, поскольку varchar сохраняется во внешних таблицах, которые занимают дополнительные байты . и, конечно, индексирование имеет значительную проблему с производительностью, когда int работает лучше, чем varchar

Суррогатный ключ – это замена естественного первичного ключа. Это просто уникальный идентификатор или номер для каждой строки, который можно использовать в качестве первичного ключа к таблице. Единственное требование к суррогатному первичному ключу – это то, что он уникален для каждой строки в таблице.

Это полезно, потому что естественный первичный ключ (то есть номер клиента в таблице клиентов) может измениться, и это затруднит обновление.

ответ дан 16 авг.

5 лет после того, как вопрос был задан и ничего полезного не добавил. – Митч Уит

Не тот ответ, который вы ищете? Просмотрите другие вопросы с метками sql database-design data-modeling surrogate-key natural-key or задайте свой вопрос.

Суррогатные и натуральные / бизнес-ключи

Будет ли нам лучше иметь бизнес-ключ в качестве первичного ключа или лучше иметь суррогатный идентификатор (то есть идентификатор SQL Server) с уникальным ограничением в поле бизнес-ключа?

Приведите примеры или доказательства, подтверждающие вашу теорию.

@Joachim Sauer: Спор о том, является ли вещь субъективной, может быть сам по себе субъективным, без какого-либо отношения к объективности или субъективности рассматриваемой вещи. Если вы не готовы указать точные объективные критерии, которые делают что-то объективным. Есть вещи, которые называются «открытыми понятиями», например, сколько волосков нужно, чтобы сделать бороду. Можно объективно сказать, что у человека без волос на подбородке нет бороды, а у человека с 5 000 волос на дюйм в длину есть борода, но где-то посередине требуется субъективное суждение, чтобы сделать объективное определение.

@Manrico: вы просто должны спросить себя: если я не буду использовать суррогатный ключ, будет ли мой первичный ключ неизменным? Если ответ отрицательный, то серьезно следует рассмотреть возможность использования суррогатного ключа. Кроме того, если первичный ключ хотя бы частично состоит из вводимых пользователем данных, вам следует рассмотреть возможность использования суррогатного ключа. Почему? Из-за опасности аномалий данных.

@TylerRick Но это не совсем хороший вопрос. Он требует решения, которое обычно применимо ко всем ситуациям, когда явно его нет, что доказано «религиозной войной», о которой спрашивающий прекрасно осведомлен (цитата: «И снова, старый аргумент все еще возникает. .. “). Вместо того, чтобы задаваться вопросом, изменился ли мир и, наконец, была предоставлена ​​веская причина выбрать одну сторону, лучше продолжать задавать этот вопрос снова и снова для каждой конкретной ситуации и публиковать в SO, если вы не уверены . Это просто обнажает догматизм.

Когда дело доходит до применения какого-либо стиля к нашему HTML, существует три подхода: встроенный, внутренний и внешний. Предпочтительным обычно.

Пытались ли вы когда-нибудь заполнить веб-форму в области электронной коммерции, которая требует много кликов и выбора? Вас попросят заполнить дату.

Будучи разработчиком веб-приложений, легко впасть в заблуждение, считая, что приложение без JavaScript не имеет права на жизнь. Нам становится удобно.

Если вы ищете пакет для быстрой интеграции календаря с выбором даты в ваше приложения, то библиотека Flatpickr отлично справится с этой задачей.

Клиент для URL-адресов, cURL, позволяет взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.

Ответы 19

Всегда используйте ключ, не имеющий коммерческого значения. Это просто хорошая практика.

Обновлено: Я пытался найти ссылку на него в Интернете, но не смог. Однако в ‘Паттерны корпоративной архитектуры’ [Fowler] есть хорошее объяснение того, почему вы не должны использовать ничего, кроме ключа, не имеющего никакого значения, кроме ключа. Это сводится к тому, что у него должна быть одна работа и только одна работа.

Мартин Фаулер может быть многим, но он не специалист по проектированию баз данных.

Я думаю, вам следует привести некоторые аргументы, прежде чем прийти к заключению.

@ArneEvertsoon Причина там. «Все сводится к тому, что у него должна быть одна работа и только одна работа». Единоличная ответственность.

У суррогатного ключа НИКОГДА не будет причин для изменения. Я не могу сказать того же о естественных ключах. Фамилии, адреса электронной почты, номера ISBN – все это может измениться в один прекрасный день.

Я считаю, что в сценарии хранилища данных лучше следовать пути суррогатного ключа. Две причины:

  • Вы не зависите от исходной системы, и изменения в ней – например, изменение типа данных – на вас не повлияют.
  • Вашему DW потребуется меньше физического пространства, поскольку вы будете использовать только целочисленные типы данных для своих суррогатных ключей. Также ваши индексы будут работать лучше.

На мой взгляд, лучше использовать суррогатный ключ, поскольку вероятность его изменения равна нулю. Почти все, что я могу придумать, что вы можете использовать в качестве естественного ключа, может измениться (отказ от ответственности: не всегда верно, но обычно).

Примером может служить база данных автомобилей – на первый взгляд может показаться, что номерной знак можно использовать в качестве ключа. Но их можно изменить, так что это плохая идея. Вы действительно не захотите узнать об этом, когда после выпускает приложение, когда кто-то приходит к вам, желая узнать, почему они не могут изменить свой номерной знак на свой новый блестящий персонализированный.

К сожалению, у автомобилей действительно есть естественный ключ, который не меняется: VIN (по крайней мере, в Америке . )

@jcollum Да ладно, это справедливый вопрос. Мое мнение все еще остается в силе, мой пример не обязательно был настолько хорош, насколько мог бы быть.

Список языков будет примером естественного ключа, если вы основываете его на кодах ISO. Поэтому, если вы затем захотите загрузить содержимое из таблицы на определенном языке, вам не нужно присоединяться к таблице languages , поскольку код языка (ID) уже находится в таблице texts .

@DanMan Я должен с тобой согласиться. Всегда найдутся примеры, которые лучше работают с естественным ключом. Правила или общие подходы никогда не бывают абсолютными, и это один из примеров, который я бы на 100% согласился с вашим подходом 🙂

Суррогатные ключи (обычно целые числа) имеют добавленную стоимость, ускоряя отношения между таблицами и делая их более экономичными с точки зрения хранения и скорости обновления (что еще лучше, внешние ключи не нужно обновлять при использовании суррогатных ключей, в отличие от полей бизнес-ключей, которые время от времени меняются).

Первичный ключ таблицы следует использовать для однозначной идентификации строки, в основном для целей соединения. Представьте себе таблицу лиц: имена могут меняться, и их уникальность не гарантируется.

Думайте о компаниях: вы счастливы, что компания Merkin ведет дела с другими компаниями в Merkia. Вы достаточно умны, чтобы не использовать название компании в качестве первичного ключа, поэтому вы используете уникальный правительственный идентификатор компании Merkia, состоящий из 10 буквенно-цифровых символов. Затем Merkia меняет идентификаторы компании, потому что они думали, что это будет хорошая идея. Ничего страшного, вы используете функцию каскадных обновлений вашего движка db для изменения, которое не должно касаться вас в первую очередь. Позже ваш бизнес расширяется, и теперь вы работаете с компанией во Фридонии. Идентификатор компании Freedonian может содержать до 16 символов. Вам необходимо увеличить первичный ключ идентификатора компании (а также поля внешнего ключа в Order, Issues, MoneyTransfers и т. д.), Добавив поле Country в первичный ключ (также во внешние ключи). Ой! Гражданская война во Фридонии, она расколота на три страны. Название страны вашего сотрудника следует изменить на новое; каскадные обновления приходят на помощь. Кстати, какой у вас первичный ключ? (Country, CompanyID) или (CompanyID, Country)? Последний помогает присоединяться, первый избегает другого индекса (или, возможно, многих, если вы хотите, чтобы ваши заказы также были сгруппированы по странам).

Все это не доказательство, а указание на то, что суррогатный ключ для однозначной идентификации строки для всех применений, включая операции соединения, предпочтительнее бизнес-ключа.

Вы выигрываете все интернет-сети с самым крутым именем пользователя!

Если бы моя свекровь прочитала мой пост, она подумала бы: «Он не говорил, что поддерживает бизнес-ключи, поэтому он категорически против уникальных бизнес-ключей, поэтому он не должен жениться на моей дочери!»; но она не будет это читать. Я считаю, что меня отвергли, потому что люди не соглашались со мной, а не потому, что это было бесполезно.

Это почти то же самое, что и отрицательный голос: «Я не согласен с этим».

Всплывающая подсказка стрелки вниз говорит: «Этот ответ бесполезен», а не «Я не согласен с этим». Возможно, в этом конкретном ответе значения близки, но в целом они не совпадают.

@jcollum: Думаю, вы никогда не читали мой предыдущий комментарий.

Если кто-то думает, что ваш ответ неправильный, то он (/ она) также будет думать, что это ведет вопрошающего в неправильном направлении (противоположном правильному), и, следовательно, сочтет ваш ответ даже хуже, чем «бесполезный», оправдывая в своем уме голос против.

@ErwinSmout: вы утверждаете очевидное, но спасибо. Итак, когда я говорю: «Первичный ключ таблицы должен использоваться для уникальной идентификации строки, в основном для целей соединения». (а затем приведите примеры), кто-то считает мой ответ неправильным и, следовательно, бесполезным; Я должен принять этот факт, не ожидая полезного аргумента. Правильно?

Как насчет решения сегодняшней проблемы сегодня и не беспокоиться так сильно о том, что может произойти в (далеком) будущем? ЯГНИ?

Ага, суррогатные ключи – это болезнь. Один утекает в дикую природу, и вы используете его как pkey, так что теперь вам нужен собственный суррогатный ключ. Затем ваш ключ утекает в дикую природу (например, через URL-адрес), и болезнь распространяется.

Вот несколько причин для использования суррогатных ключей:

Стабильность: изменение ключа из-за деловой или естественной потребности отрицательно повлияет на связанные таблицы. Суррогатные ключи редко, если вообще когда-либо, нужно менять, потому что значение не привязано к значению.

соглашение: позволяет использовать стандартизированное соглашение об именах столбцов первичного ключа вместо того, чтобы думать о том, как объединить таблицы с различными именами для их PK.

Скорость: в зависимости от значения и типа PK суррогатный ключ целого числа может быть меньше, что позволяет быстрее индексировать и искать.

Теперь, прочитав много о суррогатных и естественных ключах, я думаю, что лучше использовать суррогатные ключи. Но в моей базе данных естественные ключи (NVARCHAR (20)) должны быть уникальными. Я не понимаю, как можно увеличить скорость, если мне нужно проверять все данные в этом столбце, чтобы не повторять какое-либо значение (с использованием ограничения NOT NULL UNIQUE) при каждой вставке.

Читайте также:  Что такое сустанон в бодибилдинге

@VansFannel, насколько я знаю, index, созданный для обеспечения уникальности, позаботится о проверке повторений всякий раз, когда вы вставляете / обновляете значение.

Каковы различные типы ключей в СУБД?

каковы различные типы ключей в СУБД? Пожалуйста, приведите примеры с вашим ответом.

8 ответов

с здесь и здесь: (после того, как я погуглил ваш заголовок)

  • альтернативный ключ-альтернативный ключ – это любой ключ-кандидат, который не выбран в качестве первичного ключа
  • ключ кандидата – ключ кандидата-это поле или комбинация полей, которые могут выступать в качестве поля первичного ключа для этой таблицы для уникальной идентификации каждой записи в этой таблице.
  • составной ключ-составной ключ (также называемый составным ключом или concatenated key) – это ключ, состоящий из 2 или более атрибутов.
  • первичный ключ-первичный ключ-это значение, которое можно использовать для идентификации уникальной строки в таблице. С ним связаны атрибуты. Примерами первичных ключей являются номера социального страхования (связанные с конкретным лицом) или ISBNs (связанные с конкретной книгой). В реляционной модели данных первичный ключ-это ключ-кандидат, выбранный в качестве основного метода уникальной идентификации кортежа в отношении.
  • Superkey-суперключ определяется в реляционной модели как набор атрибутов переменной отношения (relvar), для которой он считает, что во всех отношениях, назначенных этой переменной, нет двух различных кортежей (строк), которые имеют одинаковые значения для атрибутов в этом наборе. Эквивалентно суперключ также может быть определена как набор атрибутов relvar, на которых все атрибуты relvar функционально зависимы.
  • внешний ключ – внешний ключ (FK) – это поле или группа полей в записи базы данных, которая указывает на ключевое поле или группу полей, образующих ключ другой записи базы данных в некоторой (обычно другой) таблице. Обычно внешний ключ в одной таблице относится к первичному ключу (PK) другой таблицы. Таким образом, ссылки могут быть сделаны для связывания информации вместе, и это является неотъемлемой частью нормализации базы данных

(I)Супер Ключ – атрибут или комбинация атрибутов, которые используются для уникальной идентификации записей, называется Супер-ключом. Таблица может иметь много супер ключей.

  1. ID
  2. ID, имя
  3. ID, адрес
  4. ID, Department_ID
  5. ID, зарплата
  6. Имя, Адрес
  7. Имя, Адрес, Department_ID

Так как любая комбинация, которая может идентифицировать записи однозначно будет супер ключ.

(II)Кандидат – его можно определить как минимальный супер ключ или неприводимый супер ключ. Другими словами, атрибут или комбинация атрибутов, которые однозначно идентифицируют запись, но ни один из ее собственных подмножеств не может однозначно идентифицировать записи.

Е. Г. кандидата ключа

для вышеуказанной таблицы мы имеем только 2 Ключи-кандидаты (т. е. неприводимый супер ключ), используемые для уникальной идентификации записей из таблицы. ID-ключ может идентифицировать запись однозначно и аналогично комбинация имени и адреса может идентифицировать запись однозначно, но ни имя, ни адрес не могут быть использованы для идентификации записей однозначно, как это может быть возможно, что у нас есть два сотрудника с аналогичным именем или два сотрудника из одного дома.

(III)Первичный Ключ – ключ-кандидат, используемый базой данных конструктор для уникальной идентификации каждой строки в таблице, называется первичным ключом. Первичный ключ может состоять из одного или нескольких атрибутов таблицы.

Е. Г. первичного ключа – конструктора базы данных можно использовать один из потенциальных ключей в качестве первичного ключа. В этом случае у нас есть “ID” и “Name, Address” в качестве ключа-кандидата, мы будем рассматривать ключ “ID” как первичный ключ, поскольку другой ключ-это комбинация более одного атрибута.

(IV)Внешний Ключ – внешний ключ-это атрибут или комбинация атрибутов в одной базовой таблице, которая указывает на ключ-кандидат (обычно это первичный ключ) другой таблицы. Целью внешнего ключа является обеспечение ссылочной целостности данных, т. е. допускаются только значения, которые должны отображаться в базе данных.

например. рассмотрим другую таблицу, т. е. таблицу отдела с атрибутами “Department_ID”, “Department_Name”, “Manager_ID”, “Location_ID” с Department_ID в качестве первичный ключ. Теперь атрибут Department_ID таблицы Employee (зависимая или дочерняя таблица) может быть определен как внешний ключ, поскольку он может ссылаться на атрибут Department_ID таблицы Departments (ссылочная или родительская таблица), значение внешнего ключа должно соответствовать существующему значению в родительской таблице или быть NULL.

(V)Составной Ключ – Если мы используем несколько атрибутов для создания первичного ключа, то этот первичный ключ называется составным ключом (также называется составным ключом или Объединенный Ключ).

Е. Г. от составного ключа, если мы использовали “имя, адрес” в качестве первичного ключа, то это будет наш составного ключа.

(VI)Альтернативный Ключ – альтернативным ключом может быть любой из ключей-кандидатов, кроме первичного ключа.

Е. Г. альтернативный ключ-это “имя, адрес”, так как это единственный потенциальный ключ, который не является первичным ключом.

(VII)Вторичный Ключ – атрибуты, которые даже не супер ключ но могут быть еще использованы для идентификации записей (не уникальных), известных как вторичный ключ.

Е. Г. вторичного ключа может быть имя, адрес, зарплата, Department_ID и т. д. поскольку они могут идентифицировать записи, но они не могут быть уникальными.

DeepEdit!

Первичный ключ – составной или суррогатный?

Этот выпуск посвящен “вечной” теме выбора столбцов для первичного ключа. По мотивам случайно обнаруженного замечательного ответа Тома Кайта на вопросы, заданные в 2001-2003 годах

Первичный ключ – составной или суррогатный?

У меня есть таблица из 3 полей, комбинация значений которых уникальна для каждой записи. Вот эти поля:

Ни одно из этих полей никогда не будет пустым, и ни один объект в один и тот же момент времени не будет иметь такое же значение Ticket_Number .

Поэтому мне кажется, что, вместо добавления нового поля, единственным назначением которого будет уникально идентифицировать строку в таблице, я могу использовать комбинацию этих трех полей. Но в руководстве PL/SQL Developer’s Guide рекомендуется не использовать составные первичные ключи.

Мне придется вставлять эти же значения для составных внешних ключей в несколько других таблиц. Не будет ли снижена производительность при использовании составных ключей по сравнению с простым ключом, с последовательными номерами записей? Может ли быть ее причиной необходимость сравнивать также строки и даты?

С другой стороны, если лучше добавить новое числовое поле для идентификации записей, как проще всего увеличивать значение этого поля при каждой вставке? Есть ли в Oracle подобие типа данных autonumber MS Access?

Ответ Тома Кайта

Если требуется, чтобы “эти три поля уникально идентифицировали запись в любом случае”, придется задавать по ним ограничение уникальности (UNIQUE CONSTRAINT) в любом случае. Если дублирование object_id,ticket_number,start_datetime – ошибка, ограничение уникальности НЕОБХОДИМО.

Можно добавить еще одно поле в таблицу в качестве “первичного ключа”, но это не снимает необходимости добавления ограничения уникальности по данным трем полям. Если на первичный ключ придется ссылаться во внешних ключах многих таблиц, имеет смысл использовать суррогатный ключ. Если внешних ключей немного, я бы просто использовал составной первичный ключ.

Иногда высказывают опасение, что при генерации последовательных номеров таким образом возможны пропуски (связанные с откатом транзакции, например – В.К. ).

Да, использование последовательности не гарантирует отсутствие пропусков при нумерации – в любой не однопользовательской системе они точно будут. Единственный способ нумеровать без пропусков – обрабатывать транзакции по одной. Последовательности предназначались не для этого, и любая система с таким требованием не будет масштабироваться (для компьютерных систем оно вообще смешное – при обработке документов вручную еще куда ни шло, но в компьтерной системе – оно просто бессмысленно).

Я считаю, что составные ключи прекрасно работают и могут использоваться при наличии внешних ключей, но:

  • Последовательность меньше, чем 3 столбца. Если ключ необходимо использовать как внешний в множестве других таблиц, экономия места может оказаться огромной.
  • Люди часто пытаются изменять первичный ключ, чтобы исправить данные – использование неизменного суррогатного ключа решает раз и навсегда проблему каскадных изменений , поскольку первичный ключ (значение последовательности) изменять не придется никогда – только 3 столбца данных, которые больше нигде не хранятся.
  • Проще написать: select * from p, c where p.primary_key = c.foreign_key

Эти соображения необходимо учитывать. Как я уже писал, если составной первичный ключ не используется в качестве внешнего во многих таблицах – используйте его. В противном случае серьезно задумайтесь над использованием суррогатного ключа на базе последовательности (а про “пропуски” значений не думайте вовсе – важно, что получается уникальный идентфикатор).

Составной ключ в одном столбце

Мне интересно твое мнение о том, чтро делать, если клиенты настаивают на использовании “магических кодов” – составных ключей, впихнутых в один столбец.

Лично я пыаюсь избегать такого рода идентификаторов (как бы они не генерировались) как чумы, по следующим, как мне кажется, очевидным, причинам:

  • Если при вводе данных произошла ошибка, и ключ оказался неверным (например, событие было типа 3, а не 4) – все очень печално, ведь это событие уже всем известно как 03-40123
  • Делаются конкретные предположения о максимальных значениях:
  • 1) В году никогда не будет более 10000 событий типа 1
  • 2) Нельзя добавить одиннадцатый тип события
  • 3) Две цифры года – это мы уже проходили.
  • Такие ключи неудобно реализовывать
  • Зачем вообще эта возможность узнать финансовый год и тип события без дополнительного запроса?

Я периодически сталкиваюсь с этой проблемой, обычно – при обновлении старых систем и/или систем “бумажного” документооборота, пользователи которых не хотят изменять систему нумерации. Часто мне удается уговорить клиента перейти на простые последовательности, но не всегда.

Я знаю, что ты не сторонник простых правил, но оправдывает ли природа данных или необходимость “запоминающегося” ключа создание такого типа ключей? Когда ты считаешь обоснованным использование такого составного ключевого столбца для идентфикации данных? Добавишь ли ты собственный суррогатный ключ и позволишь пользователям хранить свои магические коды где угодно, или будешь настаивать на использовании простой последовательности?

Ответ Тома Кайта

Такого рода поля могут (и должны) быть ПРОИЗВОДНЫМИ от других данных. Клиенту нет необходимости знать, как в физической схеме фактически реализован первичный ключ – это деталь реализации.

Можно даже создать индекс по функции (function-based index) по полю their_field , если они собираются искать по его значениям.

Комментарий читателя от 23 ноября 2002 года

Как я попытался объяснить в первом пункте, как только значения fy , incident_type , и goofy_number определены и строка вставлена, значение their_number тоже неявно определено. С этого момента значение their_number может выдаваться в отчетах, сообщаться заинтересованным сторонам и т.д.

Если оказывается, что, например, значение incident_type перовначально оказалось ошибочным, и оно изменяется, значения their_number в базе данных и в отчетах, у заинтересованных сторон и т.д. перестают совпадать.

Можно строить their_number по столбцам, которые не меняются, но это не всегда соответствует требованиям клиента.

Можно строить значение their_number при вставке, помещать в отдельный столбец (с ограничением уникальности, а не первичного ключа), и больше никогда его не изменять при изменении базовых значений его компонентов.

Как “эксперт”, нанятый для создания солидных моделей данных, не выхожу ли я за пределы моих полномочий (и не трачу ли зря время), часами пытаясь убедить клиентов не использовать their_number , а заменить его простым значением последовательности?

Ответ Тома Кайта

Если вы представили им все факты, как в вопросе, продемонстрировав, что это может привести к ошибкам в интерпретации данных, и они все равно настаивают на своем – вы сделали все, что могли. Можете включить СВОЙ первичный ключ в отчеты, чтобы при возникновении проблемы можно было получить соотвествующее значение. Вы не выходите за пределы своих полномочий. Я неоднократно повторял, что наша работа как раз и состоит в том, чтобы обращать на подобные вещи мнимание тех, кто не является профессиональным программистом. Последний раз пободная проблема возникла, когда меня спросили на сайте, как выбрать N случайных строк из таблицы. Я написал, как это сделать, но проблема все усложнялась, пока не выяснилось, что нужна случайная выборка 4 строк из сложного запроса со множеством соединений и т.п. Причем, выборка эта должна была делаться сотни/тысячи раз в день. Для этого требовалось множество ресурсов.

А зачем все это понадобилось? Чтобы на портале “вывесить” фотографии 4 случайно выбранных сотрудников. Я ответил: “Сообщите клиентам, что 90% ресурсов машины теперь будет уходить на выдачу этих 4 фотографий, – захотят ли они за это платить”. Мнения разделились – надо ли “знать свое место” и тупо, как бараны, делать то, что требуют, или доказывать, что практически бесполезная возможность дается дорогой ценой, и не нужна.

Я бы продолжал настаивать на своем – ваши аргументы на 100% верны. Если они решат не прислушиваться к советам, попытайтесь, по возможности, защитить их от проблем (с помощью суррогатного ключа).

Не хотел бы я работать там, где за год происходит только 9999 событий. Маловато перспектив для роста. А первого января придется этот смешной счетчик снова в 0 сбрасывать.

Ссылка на основную публикацию