SQL: где должен быть определен первичный ключ

Question

Я создаю базу данных с несколькими файлами sql 1 файл создает таблицы. 1 файл добавляет ограничения. 1 файл отбрасывает ограничения.

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

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

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

Answer 1

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

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

Answer 2

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

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

• Все операторы CREATE DOMAIN в одном файле.
• Каждый оператор CREATE TABLE в отдельном файле. Этот файл включает в себя все ограничения, кроме ограничений FOREIGN KEY, выраженных в виде операторов ALTER TABLE. (Подробнее об этом чуть позже.)
• Ограничения FOREIGN KEY каждой таблицы в отдельном файле.
• Индексы каждой таблицы для неключевых столбцов в отдельном файле.
• Триггеры каждой таблицы в отдельном файле. (Если в таблице три триггера, все три идут в одном файле.)
• Данные каждой таблицы в отдельном файле. (Только для таблиц, загруженных до перевода базы данных в оперативный режим.)
• Правила каждой таблицы в отдельном файле.
• Каждая функция в отдельном файле. (Функции являются эквивалентом PostgreSQL для хранимых процедур.)

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

Таблицы загружаются быстрее, если у них нет ограничений. Я сказал, что мы помещаем каждый оператор CREATE TABLE в отдельный файл. Файл включает в себя все ограничения, кроме ограничений FOREIGN KEY, выраженных в виде операторов ALTER TABLE. Вы можете использовать потоковый редактор sed, чтобы разбить эти файлы на две части. Один кусок имеет определения столбцов; другая часть имеет все операторы «ALTER TABLE ADD CONSTRAINT». Makefile заботится о разбиении исходных файлов и их объединении - все определения таблиц в одном файле SQL и все операторы ALTER TABLE в другом. Затем мы можем запустить один сценарий, чтобы создать все таблицы, загрузить таблицы, а затем запустить один сценарий, чтобы перестроить все ограничения.

make твой друг.

Answer 3

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

Answer 4

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

Answer 5

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