Lược đồ cơ sở dữ liệu khó hiểu (Chỉ mục và Ràng buộc)

Tôi thích cách tiếp cận thứ hai hơn. Bằng cách sử dụng số ID thay thế khi chúng không cần thiết về mặt logic để nhận dạng, bạn sẽ giới thiệu các phép nối bắt buộc hơn. Điều này yêu cầu bạn "đuổi theo số ID trên toàn bộ cơ sở dữ liệu", SQL tương đương với "đuổi theo con trỏ trên toàn bộ cơ sở dữ liệu". Con trỏ đuổi theo là đặc điểm của IMS, một trong những kiến trúc cơ sở dữ liệu mà mô hình quan hệ dự định sẽ thay thế. (IMS sử dụng kiến trúc phân cấp.) Không có lý do gì để phát minh lại nó ngày nay. (Mặc dù một lô của mọi người chỉ làm điều đó.)

Ví dụ:nếu bạn có năm cấp số ID thay thế và bạn muốn có tên của một người, bạn phải thực hiện bốn lần kết hợp để lấy. Sử dụng cách tiếp cận thứ hai, bạn chỉ cần một lần tham gia. Nếu bạn không muốn viết các phép nối nhiều cột, hãy sử dụng TẠO CHẾ ĐỘ XEM và thực hiện chỉ một lần.

Hiệu suất rất dễ kiểm tra . Chỉ cần tạo một vài triệu hàng ngẫu nhiên bằng ngôn ngữ kịch bản yêu thích của bạn và tải chúng vào một máy chủ thử nghiệm. Bạn sẽ không chỉ tìm thấy nơi các vấn đề về hiệu suất của mình đang ẩn, bạn sẽ tìm thấy tất cả các lỗi trong mã TẠO BẢNG TÍNH của mình. (Mã của bạn sẽ không hoạt động như hiện tại.) Tìm hiểu về GIẢI THÍCH nếu bạn chưa biết về nó.

Đối với lập chỉ mục , bạn có thể kiểm tra điều đó trên các hàng ngẫu nhiên mà bạn tạo và tải. Chỉ mục nhiều cột trên (first_name, last_name) sẽ hoạt động tốt nhất nếu người dùng luôn cung cấp tên. Nhưng nhiều người dùng sẽ không làm điều đó, thay vào đó họ thích tìm kiếm theo họ hơn. Chỉ mục nhiều cột trên (first_name, last_name) không hiệu quả đối với những người dùng thích tìm kiếm theo họ. Bạn có thể kiểm tra điều đó.

Chỉ vì lý do đó, việc lập chỉ mục tên và họ là thường hiệu quả hơn nếu có hai chỉ mục riêng biệt, một cho tên và một cho họ.

theo đuổi số id có tác dụng gì nghĩa là gì?

Mô hình thiết kế không thành văn làm cơ sở cho câu hỏi này là "Mọi hàng phải có số id và tất cả các khóa ngoại phải tham chiếu đến số id." Trong cơ sở dữ liệu SQL, nó thực sự là một mẫu chống. Theo nguyên tắc chung, bất kỳ mẫu nào cho phép bạn thiết kế bảng mà không cần suy nghĩ về các phím sẽ bị coi là có tội cho đến khi được chứng minh là vô tội - nó nên được coi là phản mẫu cho đến khi được chứng minh là không.

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)
);

Nếu bạn cần một báo cáo trên bảng "D", và báo cáo cần

cột D.d_1 và D.d_2 và
cột A.a_1 và A.a_2,

bạn cần 3 lần tham gia để đạt được nó. (Hãy thử nó.) Bạn đang theo đuổi số ID. (Giống như đuổi theo con trỏ trong IMS.) Cấu trúc sau khác.

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)
);

Với cấu trúc này, cùng một báo cáo cần một kết hợp duy nhất.

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;