Skema database membingungkan (Indeks dan Batasan)

Saya lebih suka pendekatan kedua. Dengan menggunakan nomor ID pengganti saat mereka tidak secara logis diperlukan untuk identifikasi, Anda memperkenalkan lebih banyak gabungan wajib. Ini mengharuskan Anda untuk "mengejar nomor ID di seluruh database", yang setara dengan SQL untuk "mengejar pointer ke seluruh database". Pointer mengejar adalah karakteristik IMS, salah satu arsitektur database model relasional dimaksudkan untuk menggantikan. (IMS menggunakan arsitektur hierarkis.) Tidak ada gunanya menciptakannya kembali hari ini. (Meskipun banyak orang melakukan hal itu.)

Jika Anda memiliki, misalnya, lima tingkat nomor ID pengganti, dan Anda menginginkan nama seseorang, Anda harus melakukan empat gabungan untuk mendapatkannya. Menggunakan pendekatan kedua, Anda hanya perlu satu bergabung. Jika Anda tidak ingin menulis gabungan multi-kolom, gunakan CREATE VIEW dan lakukan sekali saja.

Kinerja mudah untuk diuji . Cukup buat beberapa juta baris acak menggunakan bahasa skrip favorit Anda, dan muat ke server uji. Anda tidak hanya akan menemukan di mana masalah kinerja Anda bersembunyi, Anda akan menemukan semua kesalahan dalam kode CREATE TABLE Anda. (Kode Anda tidak akan berfungsi sebagaimana adanya.) Pelajari tentang MENJELASKAN jika Anda belum mengetahuinya.

Adapun pengindeksan , Anda dapat mengujinya pada baris acak yang Anda buat dan muat. Indeks multi-kolom pada (nama_depan, nama_belakang) akan berfungsi paling baik jika pengguna selalu memberikan nama depan. Tetapi banyak pengguna tidak akan melakukan itu, lebih memilih untuk mencari dengan nama belakang saja. Indeks multi-kolom pada (nama_depan, nama_belakang) tidak efektif untuk pengguna yang lebih suka mencari berdasarkan nama belakang. Anda dapat mengujinya.

Untuk alasan itu saja, pengindeksan nama depan dan nama belakang biasanya lebih efektif jika ada dua indeks terpisah, satu untuk nama depan, dan satu untuk nama belakang.

Pola desain tak terucapkan yang mendasari pertanyaan ini adalah "Setiap baris harus memiliki nomor id, dan semua kunci asing harus merujuk nomor id." Dalam database SQL, itu sebenarnya anti-pola. Sebagai aturan praktis, setiap pola yang memungkinkan Anda mendesain tabel tanpa memikirkan kunci harus dianggap bersalah sampai terbukti tidak bersalah--itu harus dianggap sebagai anti-pola sampai terbukti tidak.

create table A (
 a_id integer primary key,
 a_1 varchar(15) not null unique,
 a_2 varchar(15) not null
);

create table B (
  b_id integer primary key
  a_id integer not null references A (a_id),
  b_1  varchar(10) not null,
  unique (a_id, b_1),
);

create table C (
  c_id integer primary key,
  b_id integer not null references B (b_id),
  c_1 char(3) not null,
  c_2 varchar(20) not null,
  unique (b_id, c_1)
);

create table D (
  d_id integer primary key,
  c_id integer not null references C (c_id),
  d_1 integer not null,
  d_2 varchar(15),
  unique (c_id, d_1)
);

Jika Anda membutuhkan laporan pada tabel "D", dan laporan tersebut membutuhkan

• kolom D.d_1 dan D.d_2, dan
• kolom A.a_1 dan A.a_2,

Anda perlu 3 bergabung untuk sampai ke sana. (Cobalah.) Anda mengejar nomor ID. (Seperti mengejar pointer di IMS.) Struktur berikut ini berbeda.

create table A (
 a_1 varchar(15) primary key,
 a_2 varchar(15) not null
);

create table B (
  a_1 varchar(15) not null references A (a_1),
  b_1  varchar(10) not null,
  primary key (a_1, b_1),
);

create table C (
  a_1 varchar(15) not null,
  b_1 varchar(10) not null,
  c_1 char(3) not null,
  c_2 varchar(20) not null,
  primary key (a_1, b_1, c_1),
  foreign key (a_1, b_1) references B (a_1, b_1)
);

create table D (
  a_1 varchar(15) not null,
  b_1 varchar(10) not null,
  c_1 char(3) not null,
  d_1 integer not null,
  d_2 varchar(15),
  primary key (a_1, b_1, c_1, d_1),
  foreign key (a_1, b_1, c_1) references C (a_1, b_1, c_1)
);

Dengan struktur ini, laporan yang sama membutuhkan satu gabungan.

select D.d_1, D.d_2, A.a_1, A.a_2
from D
inner join A on D.a_1 = A.a_1;