Bảng tra cứu quan trọng như thế nào?

Câu trả lời phụ thuộc một chút nếu bạn bị giới hạn phần mềm miễn phí như PostGreSQL (không tuân thủ SQL hoàn toàn) hoặc nếu bạn đang nghĩ về SQL (tức là tuân thủ SQL) và cơ sở dữ liệu lớn.

Trong tuân thủ SQL, Kiến trúc mở cơ sở dữ liệu, nơi có nhiều ứng dụng sử dụng một cơ sở dữ liệu và nhiều người dùng sử dụng các công cụ báo cáo khác nhau (không chỉ ứng dụng) để truy cập dữ liệu, tiêu chuẩn, chuẩn hóa và các yêu cầu về kiến ​​trúc mở là rất quan trọng.

Bất chấp những người cố gắng thay đổi định nghĩa về "chuẩn hóa", v.v. để phù hợp với mục đích luôn thay đổi của họ, Chuẩn hóa (khoa học) vẫn không thay đổi.

• nếu bạn có giá trị dữ liệu chẳng hạn như {Open; Closed; etc } lặp lại trong các bảng dữ liệu, đó là trùng lặp dữ liệu , một lỗi Chuẩn hóa đơn giản:nếu bạn thay đổi các giá trị đó, bạn có thể phải cập nhật hàng triệu hàng, đây là thiết kế rất hạn chế.

  • Các giá trị như vậy phải được Chuẩn hóa thành một bảng Tham chiếu hoặc Tra cứu, với một CHAR(2) ngắn gọn PK:

    O  Open
    C  Closed
    U  [NotKnown]
    

  • Các giá trị dữ liệu {Open;Closed;etc } không còn bị trùng lặp trong hàng triệu hàng. Nó cũng tiết kiệm không gian.

  • điểm thứ hai là dễ thay đổi, nếu Closed đã được thay đổi thành Expired , một lần nữa, một hàng cần được thay đổi và điều đó được phản ánh trong toàn bộ cơ sở dữ liệu; trong khi trong các tệp chưa chuẩn hóa, cần phải thay đổi hàng triệu hàng.

  • Thêm giá trị dữ liệu mới , ví dụ. (H,HalfOpen ) thì chỉ cần chèn một hàng.

• trong Kiến trúc mở điều kiện, bảng Tra cứu là một bảng thông thường. Nó tồn tại trong danh mục [tuân thủ SQL]; miễn là FOREIGN KEY mối quan hệ đã được xác định, công cụ báo cáo cũng có thể tìm thấy điều đó.

• ENUM không phải là SQL, không sử dụng nó. Trong SQL, "enum" là một bảng Tra cứu.

• Điểm tiếp theo liên quan đến ý nghĩa của khóa.

  • Nếu Khóa vô nghĩa đối với người dùng, tốt, hãy sử dụng {INT;BIGINT;GUID;etc } hoặc bất cứ điều gì phù hợp; không đánh số chúng tăng dần; cho phép "khoảng trống".
  • Nhưng nếu Khóa có ý nghĩa với người dùng, không sử dụng một số vô nghĩa, hãy sử dụng Khóa quan hệ có ý nghĩa.

• Bây giờ một số người sẽ hiểu rõ về tính lâu dài của PK. Đó là một điểm riêng biệt. Tất nhiên, có, luôn sử dụng giá trị ổn định cho PK (không phải là "bất biến", vì không tồn tại thứ đó và khóa do hệ thống tạo không cung cấp tính duy nhất của hàng).

  • {M,F } không có khả năng thay đổi

  • nếu bạn đã sử dụng {0,1,2,4,6 }, cũng đừng thay đổi nó, tại sao bạn lại muốn. Những giá trị đó được cho là vô nghĩa, hãy nhớ rằng, chỉ cần thay đổi một Khóa có ý nghĩa.

  • nếu bạn sử dụng các khóa có ý nghĩa, hãy sử dụng các mã chữ cái ngắn để các nhà phát triển có thể dễ dàng hiểu được (và suy ra mô tả dài từ đó). Bạn sẽ đánh giá cao điều này chỉ khi bạn viết mã SELECT và nhận ra rằng bạn không cần phải JOIN mọi bảng Tra cứu. Người dùng thành thạo cũng đánh giá cao điều đó.

• Vì PK ổn định, đặc biệt là trong bảng Tra cứu, bạn có thể viết mã một cách an toàn:

  WHERE status_code = 'O' -- Open

  Bạn không cần phải JOIN bảng Tra cứu và lấy giá trị dữ liệu Open , với tư cách là nhà phát triển, bạn phải biết PK Tra cứu có nghĩa là gì.

Cuối cùng, nếu cơ sở dữ liệu lớn và được hỗ trợ các chức năng BI hoặc DSS hoặc OLAP ngoài OLTP (như cơ sở dữ liệu được chuẩn hóa đúng cách có thể), thì bảng Tra cứu thực sự là Thứ nguyên hoặc Vectơ, trong Thứ nguyên-Dữ liệu phân tích. Nếu nó không có ở đó, thì nó sẽ phải được thêm vào, để đáp ứng các yêu cầu của phần mềm đó, trước khi các phân tích như vậy có thể được kết nối.

• Nếu bạn làm điều đó với cơ sở dữ liệu của mình ngay từ đầu, bạn sẽ không phải nâng cấp nó (và mã) sau này.

Ví dụ của bạn

SQL là một ngôn ngữ cấp thấp, do đó nó cồng kềnh, đặc biệt là khi nói đến JOINs . Đó là những gì chúng ta có, vì vậy chúng ta chỉ cần chấp nhận những trở ngại và đối phó với nó. Mã ví dụ của bạn là tốt. Nhưng các biểu mẫu đơn giản hơn cũng có thể làm được điều tương tự.

Một công cụ báo cáo sẽ tạo ra:

SELECT p.*,
       s.name
    FROM posts  p, 
         status s
    WHERE p.status_id = s.status_id 
    AND   p.status_id = 'O'

Một cuộc trao đổi khác

Đối với hệ thống ngân hàng, nơi chúng tôi sử dụng các mã ngắn có ý nghĩa (vì chúng có ý nghĩa, chúng tôi không thay đổi chúng theo mùa, chúng tôi chỉ thêm vào chúng), đưa ra một bảng Tra cứu chẳng hạn như (được chọn cẩn thận, tương tự như Mã quốc gia ISO) :

Eq   Equity
EqCS Equity/Common Share
OTC  OverTheCounter
OF   OTC/Future

Mã như thế này là phổ biến:

WHERE InstrumentTypeCode LIKE "Eq%"

Và người dùng GUI sẽ chọn giá trị từ trình đơn thả xuống hiển thị
{Equity/Common Share;Over The Counter },
không phải {Eq;OTC;OF }, không phải {M;F;U }.
Nếu không có bảng tra cứu, bạn không thể làm điều đó, trong ứng dụng hoặc trong công cụ báo cáo.