Я очень плохо знаком с предметом баз данных, так что это может показаться невежественным, но мне любопытно, почему ключ должен быть явно указан в таблице. Это прежде всего для того, чтобы сообщить пользователю, что данное значение столбца (будем надеяться) гарантированно будет уникальным в каждой строке? Уникальность все еще должна быть там, даже если она не упоминается.
primary-key
unique-constraint
dsaxton
источник
источник
Ответы:
Вы, очевидно, предполагаете, что
CONSTRAINTs в базе данных должны выполняться приложениями, которые / которые обращаются к этой базе данных?Есть много причин, почему это плохая (плохая, плохая ...) идея.
1) Если вы создаете «движок ограничений« по собственной инициативе »(то есть в коде своего приложения), то вы просто эмулируете то, что потратили Oracle / SQL Server / MySQL / PostgreSQL / <. Whoever ...> годы написания. Их код CONSTRAINT был протестирован за эти годы буквально миллионами конечных пользователей.
2) При всем уважении к вам и вашей команде, вы не сможете сделать это правильно даже в течение нескольких лет - отсюда только код MySQL стоит 40 миллионов долларов. И MySQL является самым дешевым из 3 серверов выше, и они даже не реализуют ПРОВЕРКИ КОНТРОЛЯ. Очевидно, что получить RI (Referential Integrity) полностью правильно сложно.
Я часто бывал на форумах Oracle и не могу сказать вам, сколько раз какой-нибудь бедный менеджер / программист навязывал ему проект, когда у гения, который работал раньше, была «яркая» идея делать то, что вы предлагаете ,
Джонатан Льюис (он написал книгу на 550 страниц об основах оптимизатора Oracle ) дает «нет». 2 из его Дизайнерских Бедствий в другой книге (« Рассказы о Столе Дуба » - Стола Дуба - группа экспертов Оракула)
3) Даже если каким - то чудом вы можете правильно реализовать RI, вы должны полностью переопределить его снова и снова для каждого приложения , которое прикасается к этой базе данных - и если ваши данные важны, то новые приложения будут. Выбор этого в качестве парадигмы приведет вас и ваших коллег-программистов (не говоря уже о вспомогательном персонале и отделах продаж) к жизни в постоянном тушении пожаров и страданиях.
Вы можете прочитать больше о том, почему реализация CONSTRAINTs данных на уровне приложений - просто безумие здесь , здесь и здесь .
Чтобы конкретно ответить на ваш вопрос:
Причина того, что
KEYs (либоPRIMARY,FOREIGN,UNIQUEили просто обычныеINDEXадреса) объявляются в том , что, в то время как это не является строго необходимым для базы данных , чтобы иметь их для его функционирования, это абсолютно необходимо , чтобы они были объявлены для него функционировать хорошо .источник
Когда вы создаете ключ в базе данных, механизм СУБД применяет ограничение уникальности для атрибутов ключа. Это служит как минимум трем связанным целям:
источник
Я добавлю один аспект к существующим отличным ответам: Документация. Часто важно увидеть, какие ключи вы можете использовать для идентификации объекта. Любая комбинация уникальных столбцов является ключом-кандидатом.
Первичный ключ имеет тенденцию быть особенно полезным понятием на практике.
Независимо от того, применяете ли вы ключ или нет (вероятно, следует), документация сама по себе является ценной.
источник
FOREIGN KEYопределения, чтобы получить чувствую за систему ". Мой запрос вернул почтовый индекс !!! Конечно, мой SQL-код был неверным, я упомянул об этом одному из старших программистов. С гордостью (не меньше) он объявил (как будто он представлял новорожденного сына), что в системе не было никаких ФК, потому что «все поиски наPRIMARY KEYs» - (не имеет значения). <Doh ...> а-ля Гомер Симпсон!Другая причина, почему вы должны использовать CONSTRAINTs вместо некоторого внутреннего кода приложения:
Что произойдет, если разработчик / dba использует оператор вставки / обновления / удаления для изменения данных непосредственно в БД? В этом случае вся ваша хорошая ссылочная целостность приложения будет бесполезна. Я знаю, что некоторым разработчикам нравится возможность изменять данные напрямую, не беспокоясь о RI, потому что они знают, что делают - по крайней мере, большую часть времени (но не всегда)
PS: Конечно, вы можете создавать триггеры, но они обычно ужасно медленные (по сравнению с ОГРАНИЧЕНИЯМИ).
источник