Nullable Foreign Key thực hành không tốt?

Giả sử bạn có một bảng Đơn đặt hàng có khóa ngoại cho Id khách hàng. Bây giờ, giả sử bạn muốn thêm Đơn đặt hàng mà không có Mã khách hàng, (liệu điều đó có khả thi hay không là một câu hỏi khác), bạn sẽ phải đặt khóa ngoại NULL ... Đó có phải là phương pháp không tốt hay bạn muốn làm việc với bảng liên kết giữa Đơn hàng và Khách hàng? Mặc dù mối quan hệ là 1 đến n, một bảng liên kết sẽ biến nó thành n thành n. Mặt khác, với một bảng liên kết, tôi không có những NULLS đó nữa ...

Thực tế sẽ không có nhiều NULL trong cơ sở dữ liệu, bởi vì một bản ghi có khóa ngoại cho NULL chỉ là tạm thời cho đến khi khách hàng của đơn đặt hàng được thêm vào.

(Trong trường hợp của tôi, đó không phải là Đơn hàng và Khách hàng).

CHỈNH SỬA: Điều gì về một Khách hàng chưa được chỉ định để liên kết?

Có bảng liên kết có lẽ là một lựa chọn tốt hơn. Ít nhất nó không vi phạm BCNF chuẩn hóa (dạng bình thường Boyce-Codd). tuy nhiên, tôi thích thực dụng. Nếu bạn có rất ít giá trị null này và chúng chỉ là tạm thời, tôi nghĩ bạn nên bỏ qua bảng liên kết vì nó chỉ làm tăng thêm độ phức tạp cho lược đồ.

Còn một chú ý đáng nói; sử dụng bảng liên kết không nhất thiết phải biến nó thành n, nếu bạn trong bảng liên kết sử dụng khóa ngoại trỏ đến bảng đơn hàng của bạn làm khóa chính trong bảng liên kết đó thì mối quan hệ vẫn là 1..n. Chỉ có thể có một mục nhập trong bảng liên kết đó cho mỗi đơn đặt hàng.

Không Không có gì sai với Nullable FKs. Điều này thường xảy ra khi đối tượng mà FK trỏ đến có mối quan hệ (không hoặc một) đến (1 hoặc nhiều) với bảng tham chiếu Khóa chính.

Một ví dụ có thể là nếu bạn có cả thuộc tính Địa chỉ thực và thuộc tính Địa chỉ gửi thư (cột) trong một bảng, với FK đến một bảng Địa chỉ. Bạn có thể đặt Địa chỉ thực là vô hiệu để xử lý khi đối tượng chỉ có hộp thư bưu điện (địa chỉ gửi thư) và địa chỉ gửi thư không thể xử lý khi địa chỉ gửi thư giống với địa chỉ thực (hoặc không).

Các cột vô hiệu có thể ở 1NF đến 5NF, nhưng không phải trong 6NF theo những gì tôi đã đọc.

Chỉ khi bạn biết rõ hơn Chris Date "hình thức bình thường đầu tiên thực sự có nghĩa là gì". Nếu cả x và y đều có giá trị rỗng, và thực sự trong một số hàng x và y đều là giá trị nullthì WHERE x=ykhông có kết quả true. Điều này chứng tỏ rằng null không phải là một giá trị (bởi vì bất kỳ giá trị thực nào luôn bằng với chính nó). Và vì RM quy định rằng "phải có một giá trị trong mỗi ô của bảng", bất kỳ thứ nào có thể chứa null đều không phải là thứ quan hệ, và do đó câu hỏi về 1NF thậm chí không nảy sinh.

Tôi đã nghe nó tranh luận rằng các cột Nullable nói chung phá vỡ mức độ chuẩn hóa đầu tiên.

Hãy xem ở trên để biết lý do chính đáng bên dưới lập luận đó.

Nhưng trong thực tế, nó rất thực tế.

Chỉ khi bạn miễn nhiễm với những cơn đau đầu mà nó thường gây ra cho toàn bộ phần còn lại của thế giới. Một vấn đề đau đầu như vậy (và nó chỉ là một vấn đề nhỏ, so với các nullhiện tượng khác ) là thực tế rằng WHERE x=ytrong SQL thực sự có nghĩa WHERE x is not null and y is not null and x=y, nhưng hầu hết các lập trình viên chỉ đơn giản là không nhận thức được thực tế đó và chỉ đọc qua nó. Đôi khi không có bất kỳ tác hại nào, những lần khác thì không.

Trên thực tế, các cột có giá trị rỗng vi phạm một trong những quy tắc thiết kế cơ sở dữ liệu cơ bản nhất: không kết hợp các phần tử thông tin riêng biệt trong một cột. Null thực hiện chính xác điều đó bởi vì chúng kết hợp giá trị boolean "trường này / không thực sự hiện diện" với giá trị thực.

Tôi không thể thấy có gì sai khi nó chỉ là một mối quan hệ n-1 tùy chọn sẽ được biểu diễn bằng giá trị null trong khóa ngoại. Ngược lại, nếu bạn đặt bảng liên kết của mình thì bạn sẽ phải quản lý rằng nó không trở thành một mối quan hệ nn, vì vậy sẽ gây ra nhiều rắc rối hơn.

Các mối quan hệ tùy chọn chắc chắn có thể có trong mô hình quan hệ.

Bạn có thể sử dụng null để thể hiện sự vắng mặt của một mối quan hệ. Chúng rất tiện lợi, nhưng chúng sẽ khiến bạn đau đầu giống như những thứ vô hiệu gây ra cho bạn ở những nơi khác. Một nơi mà họ không gây ra bất kỳ rắc rối nào là tham gia. Các hàng có giá trị rỗng trong khóa ngoại không khớp với bất kỳ hàng nào trong bảng được tham chiếu. Vì vậy, họ bỏ ra khỏi một gia nhập nội bộ. Nếu bạn thực hiện các phép nối bên ngoài, bạn sẽ phải đối mặt với null.

Nếu bạn thực sự muốn tránh null (hình thức bình thường thứ 6), bạn có thể phân rã bảng. Một trong hai bảng đã phân tách có hai cột khóa ngoại. Một là khóa ngoại tùy chọn mà bạn có và khóa kia là khóa ngoại tham chiếu đến khóa chính của bảng gốc. Bây giờ bạn phải sử dụng các ràng buộc để ngăn mối quan hệ trở nên nhiều-nhiều, bạn muốn ngăn chặn điều đó.

Sử dụng NULL sẽ là một cách tốt để xóa các đơn hàng chưa hoàn thành:

SELECT * FROM `orders`
WHERE `started_time` < (UNIX_TIMESTAMP() + 900) AND `customer_id` IS NULL

Ở trên sẽ hiển thị các đơn đặt hàng cũ hơn 15 phút mà không có ID khách hàng liên quan.

Nếu bạn chỉ thêm đơn hàng tạm thời mà không có id khách hàng cho đến khi xác định được khách hàng, thì việc thêm khách hàng và đặt hàng trong một giao dịch sẽ không đơn giản hơn, do đó loại bỏ nhu cầu nhập khóa ngoại NULL và tránh bất kỳ ràng buộc hoặc kích hoạt nào bạn đã thiết lập để bị vi phạm?

Thông thường, tình huống này phát sinh trong các ứng dụng web nơi đơn đặt hàng được trình bày chi tiết trước khi khách hàng xác định họ là ai. Và trong những tình huống đó, đơn đặt hàng được giữ ở trạng thái máy chủ hoặc trong cookie cho đến khi tất cả trạng thái cần thiết cho một đơn đặt hàng hoàn chỉnh được cung cấp tại thời điểm đó đơn đặt hàng được lưu giữ trong cơ sở dữ liệu.

Khóa ngoại NULL là ok cho những thứ như địa chỉ, như đã đề cập ở trên. Nhưng trường khách hàng NULL không có ý nghĩa đối với một đơn đặt hàng và nên bị hạn chế.

Bạn luôn có thể thêm một hàng giả vào bảng Khách hàng của mình, chẳng hạn như Id = -1 và CustomerName = 'Unknown', sau đó trong trường hợp thông thường bạn đặt CustomerId của mình trong Order NULL, hãy đặt nó thành -1.

Điều này cho phép bạn không có FK có thể nullable nhưng vẫn thể hiện sự thiếu dữ liệu một cách thích hợp (và sẽ giúp bạn tránh khỏi những người dùng phía dưới không biết cách đối phó với NULL).

Các FK vô hiệu cho các quan hệ nhiều-một tùy chọn là hoàn toàn ổn.

Tôi đã nghe nó tranh luận rằng các cột Nullable nói chung đang phá vỡ mức độ chuẩn hóa đầu tiên. Nhưng trong thực tế, nó rất thực tế.

Có, có gì đó sai. Nó không phải là khóa ngoại nếu nó có giá trị nullable. Thiết kế cơ sở dữ liệu của nó bằng mã. Có thể bạn tạo một liên kết không đến chưa được chỉ định. hoặc "Chưa được gán" nếu bạn sử dụng ký tự col. Giữ 100% tính toàn vẹn của dữ liệu của bạn.