Sử dụng tiêu chuẩn 'Z' thay vì NULL để thể hiện dữ liệu bị thiếu?

Ngoài đối số về việc có nên sử dụng NULL hay không: Tôi chịu trách nhiệm về cơ sở dữ liệu hiện có sử dụng NULL có nghĩa là dữ liệu "bị thiếu hoặc không bao giờ được nhập". Nó khác với chuỗi rỗng, có nghĩa là "người dùng đặt giá trị này và họ đã chọn 'trống'."

Một nhà thầu khác trong dự án chắc chắn về quan điểm "NULL không tồn tại đối với tôi; tôi không bao giờ sử dụng NULL và không ai khác nên". Tuy nhiên, điều khiến tôi bối rối là vì nhóm của nhà thầu KHÔNG thừa nhận sự khác biệt giữa "thiếu / không bao giờ nhập" và "cố ý để trống hoặc được người dùng chỉ ra là không xác định", họ sử dụng một ký tự duy nhất 'Z' trong suốt mã của họ và các thủ tục được lưu trữ để đại diện cho "bị thiếu / không bao giờ được nhập" với cùng ý nghĩa với NULL trong suốt phần còn lại của cơ sở dữ liệu.

Mặc dù khách hàng được chia sẻ của chúng tôi đã yêu cầu thay đổi điều này và tôi đã ủng hộ yêu cầu này, nhóm nghiên cứu cho rằng đây là "thông lệ tiêu chuẩn" giữa các DBA cao cấp hơn nhiều so với tôi; họ miễn cưỡng thay đổi để sử dụng NULL chỉ dựa trên yêu cầu thiếu hiểu biết của tôi. Vì vậy, có ai có thể giúp tôi vượt qua sự thiếu hiểu biết của tôi? Có tiêu chuẩn nào, hoặc một nhóm nhỏ cá nhân, hoặc thậm chí một giọng nói lớn giữa các chuyên gia SQL ủng hộ việc sử dụng 'Z' thay cho NULL không?

Cập nhật

Tôi có phản hồi từ nhà thầu để bổ sung. Đây là những gì anh ấy nói khi khách hàng yêu cầu xóa các giá trị đặc biệt để cho phép NULL trong các cột không có dữ liệu:

Về cơ bản, tôi đã thiết kế cơ sở dữ liệu để tránh NULL bất cứ khi nào có thể. Đây là lý do:

• Một NULL trong trường chuỗi [VARCHAR] không bao giờ cần thiết vì một chuỗi rỗng (độ dài bằng 0) cung cấp cùng một thông tin.

• Một NULL trong trường số nguyên (ví dụ: giá trị ID) có thể được xử lý bằng cách sử dụng một giá trị sẽ không bao giờ xuất hiện trong dữ liệu (ví dụ: -1 cho trường IDENTITY số nguyên).

• NULL trong trường ngày tháng có thể dễ dàng gây ra các biến chứng trong việc tính toán ngày tháng. Ví dụ: trong logic tính toán sự khác biệt về ngày tháng, chẳng hạn như sự khác biệt về số ngày giữa [RecoveryDate] và [OnsetDate], logic sẽ bị phá hủy nếu một hoặc cả hai ngày là NULL - trừ khi có sự cho phép rõ ràng cho cả hai ngày là NULL. Đó là công việc bổ sung và xử lý thêm. Nếu ngày "mặc định" hoặc "giữ chỗ" được sử dụng cho [RecoveryDate] và [OnsetDate] (ví dụ: "1/1/1900"), các phép tính toán học có thể hiển thị các giá trị "bất thường" - nhưng logic ngày sẽ không xuất hiện.

Xử lý NULL theo truyền thống là một lĩnh vực mà các nhà phát triển mắc lỗi trong các thủ tục được lưu trữ.

Trong 15 năm làm DBA, tôi thấy tốt nhất là nên tránh NULL khi có thể.

Điều này dường như xác thực phản ứng tiêu cực cho câu hỏi này. Thay vì áp dụng cách tiếp cận 6NF được chấp nhận để thiết kế các NULL, các giá trị đặc biệt được sử dụng để "tránh NULL khi có thể." Tôi đã đăng câu hỏi này với tinh thần cởi mở và tôi rất vui vì tôi đã biết thêm về cuộc tranh luận "NULL là hữu ích / NULL là xấu", nhưng hiện tại tôi khá thoải mái khi gắn nhãn cách tiếp cận 'giá trị đặc biệt' là hoàn toàn vô nghĩa.

một chuỗi rỗng (độ dài bằng không) cung cấp cùng một thông tin.

Không, nó không; trong cơ sở dữ liệu hiện có mà chúng tôi đang sửa đổi, NULL có nghĩa là "không bao giờ được nhập" và chuỗi trống có nghĩa là "được nhập dưới dạng trống".

Xử lý NULL theo truyền thống là một lĩnh vực mà các nhà phát triển mắc lỗi trong các thủ tục được lưu trữ.

Đúng, nhưng những sai lầm đó đã được hàng nghìn lần bởi hàng nghìn nhà phát triển, và các bài học và lưu ý để tránh những sai lầm đó đã được biết đến và ghi lại. Như đã được đề cập ở đây: cho dù bạn chấp nhận hay từ chối NULL, việc biểu diễn các giá trị bị thiếu là một vấn đề đã được giải quyết . Không cần thiết phải phát minh ra một giải pháp mới chỉ vì các nhà phát triển tiếp tục mắc những lỗi dễ khắc phục (và dễ xác định).

Như một chú thích cuối trang: Tôi đã là một nhà phát triển và DBE trong hơn 20 năm (đó là thời gian đủ để tôi biết sự khác biệt giữa một kỹ sư cơ sở dữ liệu và một quản trị viên cơ sở dữ liệu). Trong suốt sự nghiệp của mình, tôi luôn ở trong trại "NULLs có ích", mặc dù tôi biết rằng một số người rất thông minh đã không đồng ý. Tôi cực kỳ nghi ngờ về phương pháp tiếp cận "giá trị đặc biệt", nhưng không đủ thông thạo về học thuật "Làm thế nào để tránh NULL con đường đúng" để tạo lập một chỗ đứng vững chắc. Tôi luôn thích học những điều mới — và tôi vẫn còn nhiều điều để học sau 20 năm. Cảm ơn tất cả những người đã đóng góp để làm cho cuộc thảo luận này trở nên hữu ích.

Sack nhà thầu của bạn.

Được rồi, nghiêm túc mà nói, đây không phải là thông lệ tiêu chuẩn. Điều này có thể được nhìn thấy đơn giản bởi vì tất cả RDBMS mà tôi đã từng làm việc với triển khai NULL, logic cho NULL, tính đến NULL trong khóa ngoại, có hành vi khác nhau đối với NULL trong COUNT, v.v.

Tôi thực sự cho rằng việc sử dụng 'Z' hoặc bất kỳ giá giữ chỗ nào khác sẽ tệ hơn. Bạn vẫn yêu cầu mã để kiểm tra 'Z'. Nhưng bạn cũng cần ghi lại rằng 'Z' không có nghĩa là 'Z', nó có nghĩa là một cái gì đó khác. Và bạn phải đảm bảo rằng tài liệu đó được đọc. Và sau đó điều gì sẽ xảy ra nếu 'Z' trở thành một phần dữ liệu hợp lệ? (Chẳng hạn như một trường cho chữ cái đầu?)

Ở cấp độ cơ bản, ngay cả khi không tranh luận về tính hợp lệ của NULL so với 'Z', tôi sẽ nhấn mạnh rằng nhà thầu tuân thủ các thông lệ tiêu chuẩn tồn tại trong công ty của bạn, không phải của họ. Việc tổ chức thực hành tiêu chuẩn của mình trong một môi trường có thực hành tiêu chuẩn thay thế sẽ gây ra nhầm lẫn, chi phí bảo trì, hiểu sai và cuối cùng làm tăng chi phí và sai lầm.

BIÊN TẬP

Theo tôi, có những trường hợp sử dụng thay thế cho NULL là hợp lệ. Nhưng chỉ những nơi làm như vậy mới giảm được mã, thay vì tạo ra các trường hợp đặc biệt yêu cầu tính toán.

Ví dụ, tôi đã sử dụng nó cho dữ liệu giới hạn ngày tháng. Nếu dữ liệu hợp lệ giữa ngày bắt đầu và ngày kết thúc, mã có thể được đơn giản hóa bằng cách không có giá trị NULL. Thay vào đó, ngày bắt đầu NULL có thể được thay thế bằng '01 tháng 1 năm 1900' và ngày kết thúc NULL có thể được thay thế bằng '31 tháng 12 năm 2079'.

Điều này vẫn có thể thay đổi hành vi so với những gì có thể mong đợi, và vì vậy nên được sử dụng cẩn thận:

• WHERE end-date IS NULL không còn cung cấp dữ liệu vẫn còn hợp lệ
• Bạn vừa tạo ra lỗi thiên niên kỷ của riêng mình
• Vân vân.

Điều này tương đương với việc cải tổ các trừu tượng sao cho tất cả các thuộc tính luôn có giá trị hợp lệ. Nó khác hẳn với việc mã hóa ngầm ý nghĩa cụ thể thành các giá trị được chọn tùy ý.

Tuy nhiên, sa thải nhà thầu.

Đây dễ dàng là một trong những ý kiến ​​kỳ lạ nhất mà tôi từng nghe. Sử dụng giá trị ma thuật để biểu thị "không có dữ liệu" thay vì NULL có nghĩa là mọi đoạn mã mà bạn có sẽ phải xử lý sau kết quả để tính toán / loại bỏ các giá trị "không có dữ liệu" / "Z".

NULL đặc biệt vì cách cơ sở dữ liệu xử lý nó trong các truy vấn. Ví dụ: lấy hai truy vấn đơn giản sau:

select * from mytable where name = 'bob';
select * from mytable where name != 'bob';

Nếu namelà NULL, nó rõ ràng sẽ không hiển thị trong kết quả của truy vấn đầu tiên. Quan trọng hơn, nó sẽ không hiển thị trong kết quả truy vấn thứ hai. NULL không khớp với bất kỳ thứ gì khác ngoài một tìm kiếm rõ ràng cho NULL, như trong:

select * from mytable where name is NULL;

Và điều gì sẽ xảy ra khi dữ liệu có thể có Z là giá trị hợp lệ? Giả sử bạn đang lưu trữ chữ cái đầu của ai đó? Liệu Zachary Z Zonkas có bị gộp chung với những người không có chữ cái đầu không? Hay nhà thầu của bạn sẽ đưa ra một giá trị kỳ diệu nào khác để xử lý việc này?

Tránh các giá trị ma thuật yêu cầu bạn triển khai các tính năng cơ sở dữ liệu trong mã mà cơ sở dữ liệu đã có đầy đủ khả năng xử lý. Đây là một vấn đề đã được giải quyết và được hiểu rõ, và có thể nhà thầu của bạn chưa bao giờ thực sự tìm hiểu khái niệm NULL và do đó tránh sử dụng nó.

Nếu miền cho phép các giá trị bị thiếu, thì việc sử dụng NULL để đại diện cho 'không xác định' là hoàn toàn OK (đó là những gì nó ở đó). Nhược điểm duy nhất là mã sử dụng dữ liệu phải được viết để kiểm tra NULL. Đây là cách tôi luôn làm.

Tôi chưa bao giờ nghe nói (hoặc thấy trong thực tế) việc sử dụng 'Z' để biểu thị dữ liệu bị thiếu. Khi "nhà thầu coi đây là" thông lệ tiêu chuẩn "giữa các DBA", anh ta có thể cung cấp một số bằng chứng về khẳng định đó không? Như @Dems đã đề cập, bạn cũng cần ghi lại rằng 'Z' không có nghĩa là 'Z': còn một MiddleInitialcột thì sao?

Giống như Aaron Alton và nhiều người khác, tôi tin rằng giá trị NULL là một phần không thể thiếu trong thiết kế cơ sở dữ liệu và nên được sử dụng khi thích hợp.

Ngay cả khi bằng cách nào đó bạn cố gắng giải thích cho tất cả các nhà phát triển và DBA hiện tại và tương lai của mình về "Z" thay vì NULL và ngay cả khi họ mã hóa mọi thứ một cách hoàn hảo, bạn vẫn sẽ nhầm lẫn với trình tối ưu hóa vì nó sẽ không biết rằng bạn đã nấu điều này .

Sử dụng một giá trị đặc biệt để đại diện cho NULL (đã là một giá trị đặc biệt để đại diện cho NULL) sẽ dẫn đến lệch dữ liệu. ví dụ: Rất nhiều điều đã xảy ra vào ngày 1 tháng 1 năm 1900 đến nỗi nó sẽ làm mất khả năng của trình tối ưu hóa để hiểu phạm vi ngày thực tế thực sự có liên quan đến ứng dụng của bạn.

Điều này giống như việc một người quản lý quyết định: "Đeo cà vạt có hại cho năng suất, vì vậy tất cả chúng ta sẽ đeo băng keo quanh cổ. Vấn đề đã được giải quyết."

Tôi chưa bao giờ nghe nói về việc sử dụng rộng rãi 'Z'để thay thế cho NULL.

(Nhân tiện, tôi đặc biệt không muốn làm việc với một nhà thầu nói thẳng với bạn rằng họ và các DBA "tiên tiến" khác hiểu biết hơn và giỏi hơn bạn rất nhiều).

 +=================================+
 |  FavoriteLetters                |
 +=================================+
 |  Person      |  FavoriteLetter  |
 +--------------+------------------+
 |  'Anna'      |  'A'             |
 |  'Bob'       |  'B'             |
 |  'Claire'    |  'C'             |
 |  'Zaphod'    |  'Z'             |
 +---------------------------------+

Nhà thầu của bạn sẽ giải thích dữ liệu từ hàng cuối cùng như thế nào?

Có lẽ anh ta sẽ chọn một "giá trị ma thuật" khác trong bảng này để tránh va chạm với dữ liệu thực 'Z'? Có nghĩa là bạn phải nhớ nhiều giá trị ma thuật và giá trị nào được sử dụng ở đâu ... điều này tốt hơn là chỉ có một mã thông báo ma thuật NULLvà phải nhớ các quy tắc logic ba giá trị (và cạm bẫy) đi kèm với nó? NULLít nhất là được tiêu chuẩn hóa, không giống như nhà thầu của bạn 'Z'.

Tôi đặc biệt không thích NULL, nhưng thay thế nó bằng một giá trị thực tế (hoặc tệ hơn, bằng một số giá trị thực tế) ở mọi nơi gần như chắc chắn tồi tệ hơn NULL.

Hãy để tôi nhắc lại nhận xét ở trên của tôi ở đây để có tầm nhìn tốt hơn: Nếu bạn muốn đọc điều gì đó nghiêm túc và có cơ sở bởi những người chống lại NULL, tôi muốn giới thiệu bài viết ngắn "Cách xử lý thông tin bị thiếu mà không sử dụng NULLs" (liên kết đến tệp PDF Trang chủ Tuyên ngôn Thứ ba ).

Về nguyên tắc, không có gì yêu cầu nulls để thiết kế cơ sở dữ liệu chính xác. Trên thực tế, có rất nhiều cơ sở dữ liệu được thiết kế mà không sử dụng null và có rất nhiều nhà thiết kế cơ sở dữ liệu rất giỏi và toàn bộ nhóm phát triển thiết kế cơ sở dữ liệu mà không sử dụng null. Nói chung, bạn nên thận trọng khi thêm null vào cơ sở dữ liệu vì chúng chắc chắn dẫn đến kết quả không chính xác hoặc không rõ ràng sau này.

Tôi chưa nghe nói về việc sử dụng Z được gọi là "thực hành tiêu chuẩn" làm giá trị giữ chỗ thay vì null nhưng tôi hy vọng nhà thầu của bạn đang đề cập đến khái niệm giá trị sentinel nói chung, đôi khi được sử dụng trong thiết kế cơ sở dữ liệu. Tuy nhiên, một cách phổ biến và linh hoạt hơn nhiều để tránh null mà không sử dụng dữ liệu "dummy" chỉ đơn giản là thiết kế chúng ra. Phân rã bảng sao cho mỗi loại dữ kiện được ghi lại trong một bảng không có thuộc tính "phụ", không xác định.

Trả lời ý kiến ​​nhà thầu

• Chuỗi trống <> NULL
• Chuỗi trống yêu cầu bộ nhớ 2 byte + đọc bù đắp
• NULL sử dụng bitmap null = nhanh hơn
• IDENTITY không phải lúc nào cũng bắt đầu từ 1 (tại sao lại lãng phí một nửa phạm vi của bạn?)

Toàn bộ khái niệm là thiếu sót theo hầu hết các câu trả lời khác ở đây

Mặc dù tôi chưa bao giờ thấy 'Z' là một giá trị ma thuật để đại diện cho null, nhưng tôi đã thấy 'X' được sử dụng để đại diện cho một trường chưa được điền vào. Điều đó nói rằng, tôi chỉ thấy điều này ở một nơi và giao diện của tôi đối với nó không phải là một cơ sở dữ liệu, mà là một tệp XML… vì vậy tôi sẽ không sẵn sàng sử dụng đối số này để trở thành thông lệ.

Lưu ý rằng chúng tôi phải xử lý đặc biệt 'X' và, như Dems đã đề cập, chúng tôi phải ghi lại nó, và mọi người đã bối rối vì nó. Để bảo vệ chúng tôi, điều này bị ép buộc bởi một nhà cung cấp bên ngoài, không phải thứ mà chúng tôi tự nấu ra!