Có gì sai với các cột nullable trong các khóa chính tổng hợp?

ORACLE không cho phép các giá trị NULL trong bất kỳ cột nào chứa khóa chính. Dường như điều tương tự cũng đúng với hầu hết các hệ thống "cấp doanh nghiệp" khác.

Đồng thời, hầu hết các hệ thống cũng cho phép các chống chỉ định duy nhất trên các cột không thể.

Tại sao các ràng buộc duy nhất có thể có NULL nhưng các khóa chính thì không thể? Có một lý do logic cơ bản cho điều này, hay đây là một hạn chế kỹ thuật?

Các khóa chính dành cho các hàng xác định duy nhất. Điều này được thực hiện bằng cách so sánh tất cả các phần của khóa với đầu vào.

Theo định nghĩa, NULL không thể là một phần của một so sánh thành công. Ngay cả một so sánh với chính nó ( NULL = NULL) sẽ thất bại. Điều này có nghĩa là một khóa chứa NULL sẽ không hoạt động.

Ngoài ra, NULL được cho phép trong khóa ngoại, để đánh dấu mối quan hệ tùy chọn. ^(*) Cho phép nó trong PK cũng sẽ phá vỡ điều này.

^(*) Một lời cảnh báo: Có khóa ngoại không có giá trị là không sạch thiết kế cơ sở dữ liệu quan hệ.

Nếu có hai thực thể Avà Bnơi Acó thể tùy chọn liên quan đến B, các giải pháp làm sạch là để tạo ra một bảng có độ phân giải (giả sử AB). Bảng đó sẽ liên kết Avới B: Nếu có là một mối quan hệ sau đó nó sẽ chứa một kỷ lục, nếu có không phải là sau đó nó sẽ không được.

Khóa chính xác định một mã định danh duy nhất cho mỗi hàng trong bảng: khi một bảng có khóa chính, bạn có một cách đảm bảo để chọn bất kỳ hàng nào từ nó.

Một ràng buộc duy nhất không nhất thiết phải xác định mỗi hàng; nó chỉ xác định rằng nếu một hàng có các giá trị trong các cột của nó, thì chúng phải là duy nhất. Điều này là không đủ để xác định duy nhất mỗi hàng, đó là điều mà một khóa chính phải làm.

Về cơ bản, không có gì sai với NULL trong khóa chính nhiều cột. Nhưng có một ý nghĩa mà nhà thiết kế có thể không có ý định, đó là lý do tại sao nhiều hệ thống gặp lỗi khi bạn thử điều này.

Hãy xem xét trường hợp của các phiên bản mô-đun / gói được lưu trữ dưới dạng một loạt các trường:

CREATE TABLE module
  (name        varchar(20) PRIMARY KEY,
   description text DEFAULT '' NOT NULL);

CREATE TABLE version
  (module      varchar(20) REFERENCES module,
   major       integer NOT NULL,
   minor       integer DEFAULT 0 NOT NULL,
   patch       integer DEFAULT 0 NOT NULL,
   release     integer DEFAULT 1 NOT NULL,
   ext         varchar(20),
   notes       text DEFAULT '' NOT NULL,
   PRIMARY KEY (module, major, minor, patch, release, ext));

5 phần tử đầu tiên của khóa chính là các phần được xác định thường xuyên của phiên bản phát hành, nhưng một số gói có phần mở rộng tùy chỉnh thường không phải là số nguyên (như "rc-foo" hoặc "vanilla" hoặc "beta" hoặc bất cứ ai khác cho người mà bốn lĩnh vực là không đủ có thể mơ ước). Nếu một gói không có phần mở rộng, thì đó là NULL trong mô hình trên và sẽ không có hại gì khi để mọi thứ theo cách đó.

Nhưng những gì là một NULL? Nó được cho là đại diện cho việc thiếu thông tin, một ẩn số. Điều đó nói rằng, có lẽ điều này có ý nghĩa hơn:

CREATE TABLE version
  (module      varchar(20) REFERENCES module,
   major       integer NOT NULL,
   minor       integer DEFAULT 0 NOT NULL,
   patch       integer DEFAULT 0 NOT NULL,
   release     integer DEFAULT 1 NOT NULL,
   ext         varchar(20) DEFAULT '' NOT NULL,
   notes       text DEFAULT '' NOT NULL,
   PRIMARY KEY (module, major, minor, patch, release, ext));

Trong phiên bản này, phần "mở rộng" của bộ dữ liệu KHÔNG phải là NULL mà mặc định là một chuỗi trống - có nghĩa là về mặt ngữ nghĩa (và thực tế) khác với NULL. Một NULL là một ẩn số, trong khi một chuỗi trống là một bản ghi có chủ ý của "một cái gì đó không có mặt". Nói cách khác, "trống rỗng" và "null" là những thứ khác nhau. Đó là sự khác biệt giữa "Tôi không có giá trị ở đây" và "Tôi không biết giá trị ở đây là gì".

Khi bạn đăng ký gói thiếu phần mở rộng phiên bản, bạn biết rằng nó thiếu phần mở rộng, vì vậy một chuỗi trống thực sự là giá trị chính xác. Một NULL sẽ chỉ đúng nếu bạn không biết liệu nó có phần mở rộng hay không, hoặc bạn biết rằng nó đã làm nhưng không biết nó là gì. Tình huống này dễ xử lý hơn trong các hệ thống trong đó các giá trị chuỗi là chuẩn, bởi vì không có cách nào để biểu diễn một "số nguyên trống" ngoài việc chèn 0 hoặc 1, sẽ cuộn lên trong bất kỳ phép so sánh nào được thực hiện sau này (có ý nghĩa riêng của nó) *.

Ngẫu nhiên, cả hai cách đều hợp lệ trong Postgres (vì chúng ta đang thảo luận về RDMBS "doanh nghiệp"), nhưng kết quả so sánh có thể thay đổi khá nhiều khi bạn ném NULL vào hỗn hợp - vì NULL == "không biết" nên tất cả kết quả so sánh liên quan đến NULL sẽ trở thành NULL vì bạn không thể biết điều gì đó chưa biết. NGUY HIỂM! Hãy suy nghĩ cẩn thận về điều đó: điều này có nghĩa là kết quả so sánh NULL lan truyền thông qua một loạt các so sánh. Đây có thể là một nguồn lỗi tinh tế khi sắp xếp, so sánh, v.v.

Postgres cho rằng bạn là người lớn và có thể tự đưa ra quyết định này. Oracle và DB2 cho rằng bạn đã không nhận ra mình đang làm điều gì đó ngớ ngẩn và gây ra lỗi. Đây thường là điều đúng, nhưng không phải lúc nào cũng vậy - bạn thực sự có thể không biết và có NULL trong một số trường hợp và do đó để lại một hàng với một yếu tố không xác định mà không thể so sánh có ý nghĩa là hành vi đúng.

Trong mọi trường hợp, bạn nên cố gắng loại bỏ số lượng trường NULL mà bạn cho phép trên toàn bộ lược đồ và gấp đôi khi nói đến các trường là một phần của khóa chính. Trong phần lớn các trường hợp, sự hiện diện của các cột NULL là một dấu hiệu của thiết kế lược đồ không được chuẩn hóa (trái ngược với cố tình không chuẩn hóa) và nên được suy nghĩ rất kỹ trước khi được chấp nhận.

[* LƯU Ý: Có thể tạo một loại tùy chỉnh là liên kết các số nguyên và loại "dưới cùng" về mặt ngữ nghĩa có nghĩa là "trống rỗng" thay vì "không xác định". Thật không may, điều này giới thiệu một chút phức tạp trong các hoạt động so sánh và thường thực sự đúng loại không đáng để nỗ lực trong thực tế vì bạn không nên cho phép nhiều NULLgiá trị ở vị trí đầu tiên. Điều đó nói rằng, thật tuyệt vời nếu các RDBMS sẽ bao gồm một BOTTOMloại mặc định bên cạnh NULLviệc ngăn chặn thói quen kết hợp các ngữ nghĩa của "không có giá trị" với "giá trị không xác định". ]

NULL == NULL -> false (ít nhất là trong DBMS)

Vì vậy, bạn sẽ không thể truy xuất bất kỳ mối quan hệ nào bằng cách sử dụng giá trị NULL ngay cả với các cột bổ sung có giá trị thực.

Câu trả lời của Tony Andrew là một câu trả lời đàng hoàng. Nhưng câu trả lời thực sự là đây đã là một quy ước được sử dụng bởi cộng đồng cơ sở dữ liệu quan hệ và KHÔNG phải là một điều cần thiết. Có lẽ đó là một quy ước tốt, có thể không.

So sánh mọi thứ với kết quả NULL trong UNKNOWN (giá trị thật thứ 3). Vì vậy, như đã được đề xuất với null, tất cả sự khôn ngoan truyền thống liên quan đến sự bình đẳng đi ra ngoài cửa sổ. Vâng, đó là cách nó có vẻ như thoạt nhìn.

Nhưng tôi không nghĩ rằng điều này nhất thiết phải như vậy và ngay cả cơ sở dữ liệu SQL cũng không nghĩ rằng NULL phá hủy tất cả khả năng để so sánh.

Chạy trong cơ sở dữ liệu của bạn truy vấn CHỌN * TỪ GIÁ TRỊ (NULL) UNION CHỌN * TỪ GIÁ TRỊ (NULL)

Những gì bạn thấy chỉ là một tuple với một thuộc tính có giá trị NULL. Vì vậy, công đoàn nhận ra ở đây hai giá trị NULL là bằng nhau.

Khi so sánh một khóa tổng hợp có 3 thành phần với một tuple với 3 thuộc tính (1, 3, NULL) = (1, 3, NULL) <=> 1 = 1 VÀ 3 = 3 VÀ NULL = NULL Kết quả của việc này là UNKNOWN .

Nhưng chúng ta có thể định nghĩa một loại toán tử so sánh mới, vd. ==. X == Y <=> X = Y HOẶC (X LÀ NULL VÀ Y LÀ NULL)

Có loại toán tử đẳng thức này sẽ làm cho các khóa tổng hợp có các thành phần null hoặc khóa không tổng hợp có giá trị null không có gì khó hiểu.

Tôi vẫn tin rằng đây là một lỗ hổng cơ bản / chức năng do một kỹ thuật mang lại. Nếu bạn có một trường tùy chọn mà bạn có thể xác định một khách hàng mà bây giờ bạn phải hack một giá trị giả vào đó, chỉ vì NULL! = NULL, không đặc biệt thanh lịch nhưng đó là một "tiêu chuẩn ngành"