Sqlserver
 sql >> база данни >  >> RDS >> Sqlserver

Съставен първичен ключ срещу допълнителен идентификационен номер колона?

Кажете това {Author, Title, Edition} уникално идентифицира книга, тогава важи следното:

  1. Това е суперключ - уникално идентифицира кортеж (ред).

  2. Не може да се намали – премахването на някоя от колоните вече не я прави ключ.

  3. Това е ключ-кандидат - нередуцируемият суперключ е кандидат-ключ.

Сега нека разгледаме ID (цяло число)

Мога да разсъждавам, че Book ключът на таблицата ще се покаже в няколко други таблици като външен ключ, а също и в няколко индекса. Така че ще отнеме доста място – да речем три колони x 40 знака (или каквото и да е...) – във всяка от тези таблици плюс съответстващи индекси.

За да направя тези "други" таблици и индекси по-малки, мога да добавя колона с уникално цяло число към Book таблица, която да се използва като ключ, който ще бъде препратен като външен ключ. Кажете нещо като:

alter table Book add BookID integer not null identity;

С BookID като (трябва да бъде) уникален също, Book таблицата вече има два кандидат-ключа.

Сега мога да избера BookID като първичен ключ.

alter table Book add constraint pk_Book primary key (BookID);

Въпреки това, {Author,Title,Edition} трябва остане ключ (уникален), за дапредотврати нещо подобно:

BookID  Author      Title           Edition
-----------------------------------------------
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

За да обобщим, добавяме BookID -- и избирането му като основно -- не спря {Author, Title, Edition} като (кандидат) ключ. Все пак трябва да има свое собствено уникално ограничение и обикновено съответстващ индекс.

Също така имайте предвид, че от гледна точка на проектиране това решение е направено на „физическо ниво“. Като цяло, на логическо ниво на дизайн, това ID не съществува - въведен е по време на разглеждането на размерите на колоните и индексите. И така, физическата схема е получена от логическата. В зависимост от размера на DB, RDBMS и използвания хардуер, нито едно от тези разсъждения за размера може да има измерим ефект - така че използвайте {Author, Title, Edition} като PK може да бъде идеално добър дизайн - докато не се докаже различно.



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Какво е логически оператор в SQL Server - SQL Server / TSQL урок, част 123

  2. Как да шифровате съхранена процедура в SQL Server

  3. Как да намерите съпоставянията на базата данни, поддържани от вашия екземпляр на SQL Server

  4. Как да конвертирате низ в дата/час в SQL Server с помощта на CAST()

  5. Какъв е низът за връзка за localdb за версия 11