Sqlserver
 sql >> Teknologi Basis Data >  >> RDS >> Sqlserver

Kunci Utama Gabungan vs kolom ID tambahan?

Katakan bahwa {Author, Title, Edition} mengidentifikasi sebuah buku secara unik, maka berikut ini berlaku:

  1. Ini adalah superkey -- secara unik mengidentifikasi sebuah tuple (baris).

  2. Ini tidak dapat direduksi -- menghapus salah satu kolom tidak membuatnya menjadi kunci lagi.

  3. Ini adalah kunci kandidat -- superkey yang tidak dapat direduksi adalah kunci kandidat.

Sekarang mari kita perhatikan ID (bilangan bulat)

Saya dapat beralasan bahwa Book kunci tabel akan muncul di beberapa tabel lain sebagai kunci asing dan juga di beberapa indeks. Jadi, ini akan memakan sedikit ruang -- misalnya tiga kolom x 40 karakter (atau apa pun...) -- di setiap tabel ini ditambah indeks yang cocok.

Untuk membuat tabel dan indeks "lainnya" ini lebih kecil, saya dapat menambahkan kolom bilangan bulat unik ke Book tabel yang akan digunakan sebagai kunci yang akan direferensikan sebagai kunci asing. Katakan sesuatu seperti:

alter table Book add BookID integer not null identity;

Dengan BookID menjadi (harus) unik juga, Book tabel sekarang memiliki dua kunci kandidat.

Sekarang saya dapat memilih BookID sebagai kunci utama.

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

Namun, {Author,Title,Edition} harus tetap menjadi kunci (unik) untuk mencegah seperti ini:

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

Singkatnya, tambahkan BookID -- dan memilihnya sebagai yang utama -- tidak menghentikan {Author, Title, Edition} menjadi kunci (kandidat). Itu masih harus memiliki batasan uniknya sendiri dan biasanya indeks yang cocok.

Perhatikan juga bahwa dari segi desain, keputusan ini dilakukan pada "tingkat fisik". Secara umum, pada tingkat logis desain, ID . ini tidak ada -- itu diperkenalkan selama pertimbangan ukuran kolom dan indeks. Jadi, skema fisik diturunkan dari skema logis. Bergantung pada ukuran DB, RDBMS, dan perangkat keras yang digunakan, tidak satu pun dari penalaran ukuran itu yang memiliki efek terukur -- jadi gunakan {Author, Title, Edition} sebagai PK mungkin merupakan desain yang sangat bagus -- sampai terbukti berbeda.



  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Kesalahan SQL Server 111:"... harus menjadi pernyataan pertama dalam kumpulan kueri"

  2. Cara Menampilkan Tanggal dalam Format Jerman di SQL Server (T-SQL)

  3. Perbedaan antara Subquery dan Subquery Berkorelasi

  4. SQL Server - Hubungan Pendek Permintaan?

  5. Temukan nilai di mana saja dalam database