Các thực tiễn tốt nhất về bảng tra cứu trong cơ sở dữ liệu quan hệ là gì?

Các bảng tra cứu (hoặc bảng mã , như một số người gọi chúng) thường là một tập hợp các giá trị có thể có thể được cung cấp cho một cột nhất định.

Ví dụ: giả sử chúng ta có một bảng tra cứu được gọi là party(có nghĩa là lưu trữ thông tin về các đảng chính trị) có hai cột:

party_code_idn, chứa các giá trị số do hệ thống tạo và (thiếu ý nghĩa miền kinh doanh ) hoạt động như một đại diện thay thế cho khóa thực.
party_code, là khóa tự nhiên thực sự hoặc trên mạng của bảng vì nó duy trì các giá trị có ý nghĩa miền kinh doanh .

Và hãy để chúng tôi nói rằng bảng như vậy giữ lại dữ liệu sau:

 +----------------+------------+
 | party_code_idn | party_code |
 +----------------+------------+
 |              1 | Republican |
 |              2 | Democratic |
 +----------------+------------+

Các party_codecột, mà giữ 'Cộng hòa' và 'Dân chủ', là chìa khóa thực sự của bảng, được thiết lập với một hạn chế UNIQUE, nhưng tôi tùy chọn thêm các giá trị party_code_idnvà định nghĩa nó như là PK của bảng (mặc dù, nói một cách logic , party_codecó thể hoạt động như KHÓA CHÍNH [PK]).

Câu hỏi

Các thực tiễn tốt nhất để trỏ đến các giá trị tra cứu từ các bảng giao dịch là gì? Tôi có nên thiết lập các tham chiếu FOREIGN KEY (FK) hoặc (a) trực tiếp đến giá trị tự nhiên và có ý nghĩa hoặc (b) để thay thế các giá trị không?

Option (a) , ví dụ,

 +---------------+------------+---------+
 | candidate_idn | party_code |  city   |
 +---------------+------------+---------+
 |             1 | Democratic | Alaska  |
 |             2 | Republican | Memphis |
 +---------------+------------+---------+

có các tính chất sau ¹ :

Có thể đọc cho người dùng cuối (+)
Dễ dàng xuất nhập khẩu trên các hệ thống (+)
Khó thay đổi giá trị vì nó cần sửa đổi trong tất cả các bảng tham chiếu (-)
Thêm giá trị mới không tốn kém (=)

Tôi nghĩ rằng nó gần giống như vượt qua bởi giá trị , để rút ra một sự tương tự từ lời gọi hàm trong thuật ngữ lập trình ứng dụng.

Tùy chọn (b) , ví dụ,

 +---------------+----------------+---------+
 | candidate_idn | party_code_idn |  city   |
 +---------------+----------------+---------+
 |             1 |              1 | Alaska  |
 |             2 |              2 | Memphis |
 +---------------+----------------+---------+

có các thuộc tính dưới đây:

Không thể đọc được cho người dùng cuối (-)
Khó xuất nhập khẩu vì chúng ta cần phải tham chiếu lại nó (-)
Dễ dàng thay đổi giá trị, vì chúng tôi chỉ lưu trữ các tham chiếu trong các bảng giao dịch (+)
Thêm giá trị mới không tốn kém (=)

Nó rất giống với Pass qua bởi tham chiếu , nếu so sánh với chức năng gọi theo cách nói lập trình ứng dụng.

Xuất nhập khẩu cũng có thể được thực hiện theo một cách khác, tức là, chỉ bằng cách điền vào bảng tra cứu một lần nữa và sau đó chọn lại cột thay thế. Tôi hy vọng tôi đang làm đúng, đây là điều mà tôi vừa nghe như một khả năng.

_{1. Lưu ý rằng +, -và =chỉ ra lợi ích của các tính chất đó.}

Câu hỏi

Khá quan trọng: Có sự khác biệt giữa bảng tra cứu (hoặc mã ) và tham chiếu FK nếu chúng ta chỉ sử dụng cách tiếp cận sau? Tôi nghĩ rằng họ làm việc như nhau.

Tài nguyên liên quan

— Nishant
nguồn

Câu trả lời:

Bởi IDN, tôi có nghĩa là bạn có nghĩa là IDENTITY, SEQUENCEhoặc AUTO_INCREMENTlĩnh vực? Bạn nên xem ở đây và ở đây .

Lưu ý, phần 5 (Sử dụng sai các giá trị dữ liệu làm thành phần dữ liệu) của tham chiếu đầu tiên, bên dưới hình 10

Tất nhiên, bạn có thể có một bảng riêng cho nhân viên bán hàng và sau đó tham chiếu bảng đó bằng khóa ngoại, tốt nhất là với khóa thay thế đơn giản như sales_person_id, được hiển thị ở trên.

Vì vậy, chuyên gia này nghĩ rằng bạn nên "trì hoãn" các khóa thay thế. Đây thực sự là một kỹ thuật SQL cơ bản và không nên gây ra sự cố trong SQL hàng ngày của bạn. Dường như có lỗi trong hình 10 - sales_person trong SalesData phải là khóa thay thế (tức là một số), không phải là văn bản. Tôi đang suy luận điều này từ trích dẫn ở trên.

Điều bạn nên tránh bằng mọi giá là sự cám dỗ (rất phổ biến đối với các lập trình viên cơ sở dữ liệu mới làm quen) để phạm lỗi được nêu trong phần (1) Các bảng tra cứu chung. Điều này thường được gọi là phương pháp Mucks ( Khóa mã thống nhất lớn ) (không phải ngẫu nhiên :-) đáng chú ý là Joe Celko , còn được gọi một cách mỉa mai là OTLT - Bảng tra cứu thực sự ) và dẫn đến đủ loại khó khăn. Các lập trình viên Novice dường như cảm thấy rằng một mã / tra cứu / bất kỳ bảng nào là "sạch hơn" và sẽ hiệu quả hơn khi không có gì có thể là sự thật.

Từ tài liệu tham khảo thứ hai ở trên:

Chuẩn hóa sẽ loại bỏ dữ liệu dư thừa, do đó làm cho nhiệm vụ thực thi tính toàn vẹn dữ liệu trở nên đơn giản hơn rất nhiều, nhưng quá trình tạo một Muck hoàn toàn khác. MỌI không loại bỏ dữ liệu dư thừa, thay vào đó chúng là loại bỏ những gì được PERCEIVED thành các bảng dự phòng, nhưng như tôi sẽ chứng minh, ít bảng hơn không bằng sự đơn giản.

Bạn cũng có thể muốn xem mô hình EAV ( Giá trị thuộc tính thực thể ) có liên quan mà tôi xử lý ở đây .

— Vérace
nguồn

Theo IDN, tôi có nghĩa là khóa ngoại được tạo tự động. Tôi không sử dụng Bảng tra cứu chung, không chắc bạn nghĩ tôi đã sử dụng bảng đó như thế nào? Chúng tôi sử dụng như hàng trăm Bảng mã thực sự. Có vẻ như thực sự kỳ lạ ai đó sẽ làm điều đó trong một bảng thống nhất. Nhưng thật tốt khi biết một mô hình như vậy tồn tại và nên tránh. EAV có vẻ thú vị. Vì vậy, sự đồng thuận là tôi nên sử dụng IDN tức là khóa thay thế?

— Nishant

Chiến lược "hội thảo" chắc chắn dường như là cách tiếp cận đa số. Tại sao không thử nghiệm một chút và xem làm thế nào bạn nhận được trên? Chọn một số khóa tự nhiên và xem SQL của bạn hoạt động như thế nào - sau đó chỉ định một đại diện thay thế và giải quyết vấn đề đó trong một thời gian. Celko và Pascal sẽ được tôn trọng trong thế giới SQL / Quan hệ, nhưng tôi đã thấy mọi người tranh cãi với họ rằng cách tiếp cận của họ quá giáo lý và thuần túy - và các hệ thống "thế giới thực" phải sử dụng các khóa thay thế. Nếu khóa tự nhiên của bạn là ba trường và đó là một trường FOREIGN KEYkhác, nó có thể trở nên khá lộn xộn nhưng YMMV.

— Vérace

Vâng tbh Tôi đã có suy nghĩ thuần túy này và tôi giống như tại sao ppl sử dụng khóa thay thế! Và sau đó một số trường hợp sử dụng dường như thực sự khó xử lý trong thế giới thuần túy. Tôi cảm thấy rằng phương pháp thay thế dễ dàng hơn mặc dù bạn có một số nhược điểm của việc nhập và xuất. Quả thực kịch bản kết hợp có thể phức tạp hơn. Bảng mã Btw không khác nhiều so với Khóa ngoài trong kịch bản thay thế phải không? Ý tôi là sự khác biệt logic tồn tại nhưng không có gì ngoài Khóa ngoại.

— Nishant

Bạn có thể thực thi các khóa tự nhiên của mình thông qua UNIQUE CONSTRAINTs và NOT NULLs - tốt, các mục trong Bảng mã của bạn nằm FOREIGN KEYtrong các bảng sử dụng / tham chiếu đến chúng - vì vậy các khái niệm có liên quan, nhưng không giống nhau. Khóa thay thế của Bảng mã là trường xuất hiện trong bảng "con" - chắc chắn ít dễ đọc hơn, nhưng INTkhông lớn lắm - không cần nhiều không gian, đó là một lợi thế của khóa thay thế.

— Vérace

Có một cách tiếp cận thứ ba có một số ưu điểm của hai tùy chọn của bạn - đặt mã thực tế vào bảng mã. Bằng cách này, tôi có nghĩa là một chuỗi ký tự ngắn nắm bắt được bản chất của giá trị đầy đủ và là duy nhất. Ví dụ của bạn có thể là

Idn: 1
Name: Democrats
Code: D      (or DEM)

Mã được mang vào các bảng giao dịch dưới dạng khóa ngoại. Nó ngắn, dễ hiểu và hơi độc lập với dữ liệu "thực". Thay đổi tăng dần cho tên sẽ không đề xuất thay đổi mã. Có nên đảng Cộng hòa bỏ trốn hàng loạt , tuy nhiên, một sự thay đổi mã có thể cần thiết, với những vấn đề tiếp viên của mình rằng một id thay thế sẽ không phải chịu.

Phong cách này đã được gọi là mã hóa viết tắt. Tôi có thể đề nghị Celko viết về điều này. Sách Google giữ một số ví dụ. Tìm kiếm "mã hóa Celko".

Các ví dụ khác: mã hóa 2 hoặc 3 chữ cái cho các quốc gia, mã hóa 3 chữ cái (GBP, USD, EUR) cho mã tiền tệ. Ngắn gọn, tự giải thích và không thay đổi (và có ISO cho họ).

— Michael Green
nguồn