Первичные и внешние ключи — это связующее звено, которое объединяет несколько таблиц в эффективную реляционную базу данных. Конструкция первичных и внешних ключей оказывает решающее влияние на производительность и доступность физической базы данных.
Схема базы данных должна быть преобразована из теоретического логического проекта в реальный физический проект. Структура первичных и внешних ключей является сутью этого процесса проектирования. После того, как спроектированная база данных будет использоваться в производственной среде, эти ключи будет сложно изменить, поэтому очень важно и целесообразно спроектировать первичные ключи и внешние ключи на этапе разработки.
Первичный ключ:
Реляционные базы данных полагаются на первичные ключи — краеугольный камень физической схемы базы данных. Первичные ключи имеют только две цели на физическом уровне:
1. Уникально идентифицировать строку.
2. Как объект, на который можно эффективно ссылаться по внешним ключам.
Основываясь на двух вышеупомянутых способах использования, вот несколько принципов, которым я следую при разработке первичных ключей на физическом уровне:
1. Первичный ключ не должен иметь смысла для пользователя. Если пользователь видит в объединяющей таблице данные, представляющие связь «многие ко многим», и жалуется, что от них мало пользы, это доказывает, что их первичный ключ хорошо спроектирован.
2. Первичный ключ должен представлять собой один столбец, чтобы повысить эффективность операций соединения и фильтрации.
Примечание. Люди, использующие составные ключи, обычно извиняют себя по двум причинам, обе из которых неверны. Во-первых, первичный ключ должен иметь реальное значение. Однако придание смысла первичному ключу обеспечивает лишь удобство для искусственного уничтожения базы данных. Во-вторых, вы можете использовать этот метод для использования двух внешних ключей в качестве первичных ключей в объединяющей таблице, описывающей отношения «многие ко многим». Я также против этого подхода, потому что: составные первичные ключи часто приводят к плохим внешним ключам; то есть при объединении таблиц стать главной таблицей другой подчиненной таблицы и стать частью первичного ключа этой таблицы в соответствии со вторым методом, описанным выше. Однако эта таблица может стать главной таблицей других подчиненных таблиц и ее первичным ключом. может стать главной таблицей других подчиненных таблиц. Если она передается таким образом как часть первичного ключа, то чем позже будет подчиненная таблица, тем больше столбцов будет содержать ее первичный ключ.
3. Никогда не обновляйте первичные ключи. Фактически, поскольку первичный ключ не имеет никакой другой цели, кроме уникальной идентификации строки, нет смысла его обновлять. Если первичный ключ необходимо обновить, нарушается принцип, согласно которому первичный ключ не должен иметь смысла для пользователя.
Примечание. Этот принцип не применяется к данным, которые часто необходимо систематизировать во время преобразования данных или объединения нескольких баз данных.
4. Первичный ключ не должен содержать динамически изменяющиеся данные, такие как временная метка, столбец времени создания, столбец времени модификации и т. д.
5. Первичный ключ должен быть автоматически сгенерирован компьютером. Если человек вмешивается в создание первичного ключа, это будет иметь иное значение, чем однозначное определение строки. Как только эта граница будет пересечена, может возникнуть стимул изменить первичный ключ, так что средства ключа, используемые этой системой для связывания строк записей и управления ими, попадут в руки людей, которые не разбираются в конструкции базы данных.
Внешний ключ — это ограничение целостности на уровне базы данных, которое представляет собой метод реализации «ссылочной целостности» базы данных, упомянутый в книге по базовой теории баз данных.
Конечно, атрибут внешнего ключа можно удалить. Если вы больше не хотите использовать это ограничение, это, конечно, не окажет никакого влияния на программирование, но при вводе данных проверка «ссылочной целостности» для введенных данных выполняться не будет. .
Например, есть две таблицы
A(a,b): a — первичный ключ, b — внешний ключ (из Bb)
B(b,c,d): b — первичный ключ.
Если я удалю атрибут внешнего ключа поля b, это не окажет никакого влияния на программирование.
Как указано выше, b в A либо пусто, либо является значением, которое существует в b в B. При наличии внешнего ключа база данных автоматически проверит, существует ли b в A в b в B.
1. Внешнее выражение выражает ссылочную целостность: она присуща данным и не имеет ничего общего с программой. Поэтому это следует оставить на усмотрение СУБД.
2. Использование внешних баз данных просто и интуитивно понятно и может быть непосредственно отражено в модели данных. Это дает большие преимущества с точки зрения проектирования, обслуживания и т. д., особенно при анализе существующих баз данных. Преимущества очень очевидны — я не анализировал их. Давным-давно я нашел существующую корпоративную базу данных. Некоторые ограничения ссылочной целостности в ней описываются внешними ключами, а некоторые реализованы с помощью триггеров. Это кажется очень очевидным. Конечно, он может быть в документе, но может быть неполным, но внешние ключи очень очевидны и интуитивно понятны.
3. Поскольку для выполнения этой работы мы можем использовать триггеры или программы (имеется в виду ограничения ссылочной целостности), СУБД предоставляет такие средства, почему мы должны делать это самостоятельно? И надо сказать, что то, что мы делаем, не так хорошо, как РСУБД. Фактически, ранние СУБД не имели внешних ключей, но теперь они есть у всех, я думаю, что производителям баз данных имеет смысл добавить эту функцию. С этой точки зрения внешние ключи более удобны.
4. Что касается удобства, то, судя по проектам, которые я вел, программисты сообщали, что в основном было сложно вводить данные во время отладки: если данные могут нарушать ссылочную целостность, то сама ссылочная целостность не конфликтует с репутационным бизнесом. программу триггерного фьючерса использовать нельзя, в противном случае это означает, что данные неверны и вообще не должны вводиться в базу данных! Более того, это тоже должно быть частью тестовой системы: блокировка нелегальных данных. Фактически, интерфейсная программа должна обрабатывать эту ошибку отправки. Данные принадлежат предприятию, а не программе. Сохраненные программы должны быть максимально отделены от данных, и наоборот.
Наконец, позвольте мне рассказать о нескольких принципах построения ключей:
1. Создайте внешние ключи для связанных полей.
2. Все ключи должны быть уникальными.
3. Избегайте использования составных ключей.
4. Внешние ключи всегда связаны с уникальными ключевыми полями.
Эта статья взята из блога CSDN. При перепечатке указывайте источник: http://blog.csdn.net/c04s31602/archive/2009/12/30/5107568.aspx.