Почему ключ должен быть явным?

15

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

primary-key unique-constraint

— dsaxton
источник

Вы имеете в виду, что если у вас есть УНИКАЛЬНЫЙ ключ, зачем вам нужен ПЕРВИЧНЫЙ?

— Верас

1

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

— dsaxton

1

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

— Андрей М,

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

— Торбьерн Равн Андерсен

32

Вы, очевидно, предполагаете, что CONSTRAINTs в базе данных должны выполняться приложениями, которые / которые обращаются к этой базе данных?

Есть много причин, почему это плохая (плохая, плохая ...) идея.

1) Если вы создаете «движок ограничений« по собственной инициативе »(то есть в коде своего приложения), то вы просто эмулируете то, что потратили Oracle / SQL Server / MySQL / PostgreSQL / <. Whoever ...> годы написания. Их код CONSTRAINT был протестирован за эти годы буквально миллионами конечных пользователей.

2) При всем уважении к вам и вашей команде, вы не сможете сделать это правильно даже в течение нескольких лет - отсюда только код MySQL стоит 40 миллионов долларов. И MySQL является самым дешевым из 3 серверов выше, и они даже не реализуют ПРОВЕРКИ КОНТРОЛЯ. Очевидно, что получить RI (Referential Integrity) полностью правильно сложно.

Я часто бывал на форумах Oracle и не могу сказать вам, сколько раз какой-нибудь бедный менеджер / программист навязывал ему проект, когда у гения, который работал раньше, была «яркая» идея делать то, что вы предлагаете ,

Джонатан Льюис (он написал книгу на 550 страниц об основах оптимизатора Oracle ) дает «нет». 2 из его Дизайнерских Бедствий в другой книге (« Рассказы о Столе Дуба » - Стола Дуба - группа экспертов Оракула)

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

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

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

Чтобы конкретно ответить на ваш вопрос:

Почему они вообще объявлены? Это кажется очень полезным, но действительно ли необходимо иметь базу данных, которая функционирует

Причина того, что KEYs (либо PRIMARY, FOREIGN, UNIQUEили просто обычные INDEXадреса) объявляются в том , что, в то время как это не является строго необходимым для базы данных , чтобы иметь их для его функционирования, это абсолютно необходимо , чтобы они были объявлены для него функционировать хорошо .

— Verace
источник

1

Спасибо за Ваш ответ. Мне, вероятно, нужно узнать больше, чтобы полностью понять это. (На самом деле я не принадлежу к команде, я просто изучаю базы данных из любопытства.)

— dsaxton

2

Прочитайте несколько книг (Свидание, Гарсия-Молина ...) и возвращайтесь к нам, если у вас есть конкретные вопросы (слишком широкие вопросы здесь рассматриваются не по теме). ps Добро пожаловать на форум :-)

— Vérace

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

— jpmc26

10

Когда вы создаете ключ в базе данных, механизм СУБД применяет ограничение уникальности для атрибутов ключа. Это служит как минимум трем связанным целям:

Целостность данных: дубликаты данных не могут быть введены в ключевые атрибуты. Любые зависимости от ключей поэтому гарантированы.
Идентификация: пользователи могут полагаться на ключи как средство идентификации и точного обновления данных.
Оптимизация: информация (метаданные) о том, какие атрибуты являются уникальными, доступна оптимизатору запросов СУБД. Эта информация позволяет оптимизатору упростить выполнение запросов определенным образом, чтобы запросы выполнялись быстрее.

— nvogel
источник

8

Я добавлю один аспект к существующим отличным ответам: Документация. Часто важно увидеть, какие ключи вы можете использовать для идентификации объекта. Любая комбинация уникальных столбцов является ключом-кандидатом.

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

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

— boot4life
источник

1

Диаграммы базы данных! Первое, что я всегда делаю, когда меня просят сказать что-то осмысленное о программном обеспечении, с которым я не знаком, это посмотреть, использует ли оно реляционную базу данных, и если это так, попробуйте создать диаграмму базы данных. Это даст мне отличное представление об информации, с которой работает приложение. К сожалению, 90% баз данных, которые я видел, не объявляют внешние ключи, поэтому диаграммы - это просто наборы таблиц. Вывод неявных внешних ключей на уровне приложения требует догадок и подстройки.

— 10.07.15

1

@reinierpost Я полностью согласен. Данные являются наиболее ценным объектом для документирования и хранения в чистоте, потому что они сохраняются навсегда. Код может измениться; это имеет тенденцию быть более переходным.

— boot4life

@reinierpost - обратился за консультацией к компании, которая поставляла программное обеспечение для всей железнодорожной инфраструктуры большой европейской страны (крупные - думаю, миллиарды виджетов), и я сказал: «Хм, я просто запрошу запрос, чтобы проверить FOREIGN KEYопределения, чтобы получить чувствую за систему ". Мой запрос вернул почтовый индекс !!! Конечно, мой SQL-код был неверным, я упомянул об этом одному из старших программистов. С гордостью (не меньше) он объявил (как будто он представлял новорожденного сына), что в системе не было никаких ФК, потому что «все поиски на PRIMARY KEYs» - (не имеет значения). <Doh ...> а-ля Гомер Симпсон!

— Вераси

5

Другая причина, почему вы должны использовать CONSTRAINTs вместо некоторого внутреннего кода приложения:

Что произойдет, если разработчик / dba использует оператор вставки / обновления / удаления для изменения данных непосредственно в БД? В этом случае вся ваша хорошая ссылочная целостность приложения будет бесполезна. Я знаю, что некоторым разработчикам нравится возможность изменять данные напрямую, не беспокоясь о RI, потому что они знают, что делают - по крайней мере, большую часть времени (но не всегда)

PS: Конечно, вы можете создавать триггеры, но они обычно ужасно медленные (по сравнению с ОГРАНИЧЕНИЯМИ).

— Томас Франц
источник