Có thực hành tốt để đặt tất cả các cột cơ sở dữ liệu là NOT NULL không?

Question

Thông thường là thực hành tốt để đặt tất cả các cột cơ sở dữ liệu là NOT NULL hay không? Biện minh cho câu trả lời của bạn.

Answer 1

No. Bạn nên đặt cột thành NULL khi thích hợp.

Answer 2

Tôi không đồng ý với quy tắc "nếu thích hợp". Nó thực sự là khá an toàn để đặt bất kỳ cột nào là NOT NULL; và sau đó sửa đổi các cột để cho phép các giá trị NULL khi bạn cần chúng. Mặt khác, nếu bạn cho phép các giá trị NULL trước và sau đó quyết định bạn không muốn cho phép chúng, nó có khả năng có thể khó khăn hơn nhiều để thực hiện việc này.

Có thể làm cho mô tả bảng/cột cơ sở dữ liệu của bạn khá xấu nếu bạn làm điều này quá mức, nhưng khi nghi ngờ, hãy tiếp tục và hạn chế dữ liệu.

Answer 3

Câu trả lời ngắn: tùy thuộc vào những gì bạn đang lưu trữ.

Tôi có thể thấy một bảng (hoặc hai) có tất cả NOT NULLS hoặc tất cả NULLS. Nhưng toàn bộ cơ sở dữ liệu?

Answer 4

Chỉ dành cho các cột không có giá trị không có ý nghĩa gì.

Mòng biển có thể rất tiện dụng; cho một điều, chúng nén đẹp. Họ có thể là một bất ngờ khó chịu khi bạn không mong đợi họ, vì vậy, nếu bạn không thể có một sinh viên mà không có một tên đầu tiên - làm cho cột đó NULL. (Tên đệm, mặt khác ... có thể bạn muốn có một chuỗi rỗng mặc định, có thể không phải là đối số mặc định theo cả hai cách)

Answer 5

Bạn không nên quên đặt không rỗng khi cần, sử dụng các ràng buộc kiểm tra nếu có , đừng quên những hạn chế duy nhất, tạo chỉ mục thích hợp và đánh răng sau mỗi bữa ăn và trước khi đi ngủ :)

Trong hầu hết các trường hợp, bạn có thể sử dụng không null và không nên sử dụng. Nó dễ dàng hơn để thay đổi không null-> null so với hướng ngược lại, nhưng ví dụ trong chuỗi rỗng của Oracle được coi là null, vì vậy rõ ràng là bạn không thể sử dụng nó mọi lúc.

Answer 6

Tùy thuộc vào những gì bạn đang cố gắng làm, nhưng đối với nhiều ứng dụng, bạn nên tránh NULL s nếu có thể — và cách dễ nhất để làm điều này là sử dụng NOT NULL.

Vấn đề là ý nghĩa của NULL được mở để diễn giải. Nó có thể có nghĩa là “ không có giá trị thuộc về đây, ” hoặc có thể là “ chúng tôi chưa có giá trị, vì vậy chúng tôi nên tiếp tục yêu cầu người dùng cho số. ” Nếu bạn đang sử dụng nó, bạn sẽ muốn đọc lên trên SQL của 3-valued logic, và các chức năng như COALESCE vv

Tuy nhiên, như Cletus và những người khác đã nói, nếu bạn sử dụng một cách thích hợp NULL nó có thể hữu ích .

Answer 7

Các nhà phát minh của tham chiếu NULL (1965) thời gian gần đây gọi đó là "sai lầm tỷ đô la" của mình: http://qconlondon.com/london-2009/presentation/Null+References:+The+Billion+Dollar+Mistake

Ngôn ngữ như Scala, SML, và Haskell đều là phòng không NULL theo mặc định: NULL được gọi là "Tùy chọn "hoặc" Có thể "và yêu cầu cú pháp và kiểm tra đặc biệt.

Kể từ khi cơ sở dữ liệu thời gian được phát minh, cho phép NULL theo mặc định đã được coi là ngày càng nguy hiểm và không mong muốn. Cơ sở dữ liệu có nên theo dõi không? Có lẽ.

Đi với NOT NULL khi bạn có thể.

Answer 8

IMO, sử dụng tùy chọn NULLable phải được giảm thiểu. Ứng dụng sẽ chỉ định một giá trị phù hợp cho trạng thái "không tồn tại". Trong Peoplesoft tôi nghĩ rằng, ứng dụng đặt một 0 cho Numericals và một không gian cho các cột Char, nơi một giá trị không tồn tại.

Người ta có thể tranh luận tại sao giá trị được gọi là không phù hợp là NULL.

Vì việc triển khai SQL xử lý các giá trị rỗng hoàn toàn khác nhau.

Ví dụ: 1 = NULL và 0 = NULL cả hai kết quả là sai! NULL = NULL là sai! Giá trị NULL trong GROUP BY và các hàm tổng hợp khác cũng tạo ra kết quả không mong muốn.

Answer 9

Từ quan điểm của tôi, mặc dù nó có thể tốt hơn cho cơ sở dữ liệu, nhưng không tốt hơn cho người dùng. Một khi bạn nhận được vào các ứng dụng tương tác nhiều hơn, bạn muốn để có thể tồn tại dữ liệu trong một trạng thái tạm thời, vì vậy hầu hết các lĩnh vực của bạn có thể sẽ là null tại thời điểm đó.

Answer 10

Lý thuyết quan hệ có nó là NULL là điều xấu.

Tuy nhiên, loại câu hỏi của bạn được gọi là thực hành.

Vì vậy, trong phạm vi bạn muốn thực hành phù hợp với lý tưởng trên trời của lý thuyết, vâng, tránh NULL như thể đó là bệnh dịch hạch, Bệnh tả và AIDS tất cả-trong-một.

Trong phạm vi các triển khai crappy này được gọi là "SQL DBMS" không để lại cho bạn bất kỳ lựa chọn nào khác, có, (đánh hơi) sử dụng chúng.

EDIT

Có người nói "quy tắc kinh doanh" như kim chỉ nam cho "phù hợp" trong câu trả lời được chấp nhận, và một số người khác bỏ phiếu tán rằng nhận xét. Đó là tổng số crap. Quy tắc kinh doanh luôn có thể thực hiện mà không có NULL s và hướng dẫn duy nhất cho "sự phù hợp" là sự thiếu sót của bất kỳ hệ thống SQL nào làm cho nó trở thành một hệ thống phi quan hệ để khởi động.

Answer 11

Nếu bạn không thể biết giá trị tại thời điểm chèn, bạn thực sự phải có một giá trị rỗng. Ví dụ: giả sử bạn có hồ sơ bao gồm hai trường, ngày bắt đầu và ngày kết thúc. Bạn biết ngày bắt đầu khi bản ghi được chèn vào nhưng không phải là ngày kết thúc. Tạo một ngày giả để đưa vào lĩnh vực này chỉ để tránh nulls là câm để nói rằng ít nhất.

Trong cuộc sống thực, ít nhất là nhiều tác hại là do buộc nhập dữ liệu vào một trường bằng cách không ép buộc. Nếu bạn havea một lĩnh vực email và không biết email của khách hàng, sau đó người dùng phải làm một cái gì đó lên để đưa vào lĩnh vực yêu cầu. Có khả năng những gì họ tạo ra có thể không phải là những gì bạn sẽ muốn họ tạo nên một cái gì đó như "thisistupid@ass.com". Đôi khi thông tin xấu này được cung cấp lại cho khách hàng hoặc cho một nhà cung cấp trong một nguồn cấp dữ liệu và công ty của bạn trông thực sự thực sự ngu ngốc. Tôi biết khi tôi xử lý nhiều nguồn cấp dữ liệu này từ khách hàng của chúng tôi. Những điều tốt đẹp trong lĩnh vực email đã bao gồm, "thư ký của ông là cô gái tóc vàng béo", "anh chàng này là một jerk" vv

Answer 12

Trong các ứng dụng kinh doanh, tôi luôn loại bỏ NOT NULLS vì người dùng không thích bị buộc phải nhập dữ liệu mà họ không biết.Nó phụ thuộc vào bảng nhưng tôi thiết lập hầu hết các lĩnh vực của tôi để NULL và chỉ thiết lập số lượng tối thiểu của các lĩnh vực để NOT NULL.

Answer 13

Nếu dữ liệu của bạn thực sự có thể KHÔNG "không xác định" và điều quan trọng là phải ghi lại thực tế đó, thì có, sử dụng NULL. Lưu ý rằng đôi khi bạn cần phân biệt giữa "không xác định" và "không liên quan" - ví dụ: trường DateTime trong một trong các cơ sở dữ liệu của tôi có thể là ngày tối thiểu của SQL Server (không áp dụng), NULL (không xác định) hoặc bất kỳ ngày khác (giá trị đã biết).

Đối với các trường không thực sự có quy tắc kinh doanh tùy thuộc vào chúng - tôi đang nói về cột "Nhận xét", "Mô tả", "Ghi chú" ở đây - sau đó tôi đặt chúng thành mặc định thành chuỗi trống, như (a) nó tiết kiệm giao dịch với null, và (b) chúng không bao giờ "không rõ" - chúng không được điền vào, mà một cách hợp lý là một giá trị rỗng đã biết.

ví dụ .:

 
CREATE TABLE Computer (
    Id INT IDENTITY PRIMARY KEY 
    , Name NVARCHAR(16) NOT NULL 
    , ...[other fields]... 
    , Comments NVARCHAR(255) NOT NULL 
     CONSTRAINT DF_Computer_Comments DEFAULT (N'') 
) 

Nếu bạn không cung cấp một giá trị để nhận xét, nó mặc định là rỗng.

Answer 14

Giải pháp thay thế là gì?

Tôi đã tìm thấy câu hỏi này là kết quả của cuộc thảo luận tại nơi làm việc. câu hỏi của chúng tôi là:

Chúng ta có nên có một nullable nước ngoài chủ chốt hoặc một hiệp hội bảng với các ràng buộc duy nhất? Bối cảnh là đôi khi có sự liên kết và đôi khi không có. (EG: không có kế hoạch so với lịch dự kiến)

Đối với tôi, một sự kết hợp của chính nước ngoài nullable với một 'lĩnh vực thiết lập để null trên delete' tương đương với bảng hiệp hội nhưng có hai ưu điểm:

1. More dễ hiểu (schema là đã phức tạp)
2. dễ dàng hơn để tìm lịch trình 'ngoài ý muốn' với một 'xxx là null' truy vấn (so với không tồn tại truy vấn)

Nói tóm lại, đôi khi 'null' (các vắng mặt hình thành) thực sự có nghĩa là một cái gì đó. Cố gắng có không null, nhưng có những ngoại lệ.

FWIW, chúng tôi đã sử dụng Scala/Squeryl nên, trong mã, trường này là 'Tùy chọn' và khá an toàn.

Answer 15

Việc tôi thực hiện là nếu bạn muốn có các bảng linh hoạt và "không rõ ràng" ở một mức độ nào đó, chỉ cần sử dụng NoSQL, vì nó được xây dựng chính xác cho mục đích đó. Nếu không, có một giá trị NULL trong một hàng chỉ là chấp nhận được vì nó có thể là một phần dữ liệu tùy chọn, như Địa chỉ 2, hoặc số điện thoại nhà và loại thứ đó.

Theo quan điểm của tôi, làm cho khóa ngoại không thể phá vỡ một trong những lý do chính chúng tôi sử dụng cơ sở dữ liệu quan hệ. Khi bạn muốn dữ liệu của mình liên quan chặt chẽ và nhất quán nhất có thể.

Answer 16

Tôi là một người mới và câu trả lời của tôi có thể hoàn toàn hợp lý, nhưng đây là ý kiến ​​cá nhân của tôi về chủ đề này.

Theo quan điểm khiêm tốn của tôi, tôi không thấy vấn đề với việc cho phép TẤT CẢ các trường ngoại trừ các khóa chính/khóa ngoài không thể thực hiện được. Tôi biết nhiều người trong số các bạn đã khóc ngay khi tôi nói điều đó, và tôi chắc chắn rằng tôi nghe thấy ai đó hét lên, "Heretic! Đốt anh ta vào cổ phần!"Nhưng đây là lý do của tôi:

Thực sự là công việc của cơ sở dữ liệu để thực thi các quy tắc về giá trị nào và không được phép - ngoại trừ khóa học cần thiết để thực thi những thứ như tính toàn vẹn tham chiếu và kiểm soát mức tiêu thụ bộ nhớ bởi có những thứ như max ký tự thiết lập)? nó sẽ không được dễ dàng hơn và tốt hơn để thực thi tất cả các "null vs không null" quy tắc ở cấp đang trước khi lưu trữ các giá trị trong cơ sở dữ liệu?

Sau khi tất cả, đó là công việc của mã để xác nhận tất cả các giá trị trước khi chúng được lưu trữ trong cơ sở dữ liệu, đúng không? Vậy tại sao cơ sở dữ liệu cố gắng chiếm đoạt quyền hạn của mã bằng cách thiết lập các quy tắc về giá trị nào s là hợp lệ? Ngoài ra, bất cứ khi nào một ràng buộc được thực thi ở cấp cơ sở dữ liệu, nó nhất thiết phải được thực thi tại mã cấp cũng để ngăn chặn các mã từ "thổi lên." Vậy tại sao làm gấp đôi công việc?

Ít nhất là đối với tôi, có vẻ như mọi thứ hoạt động tốt hơn khi cơ sở dữ liệu của tôi được cho phép đơn giản là "vùng lưu trữ dữ liệu câm" bởi vì trước đây tôi đã cố gắng sử dụng "NOT NULL" để thực thi quy tắc kinh doanh có ý nghĩa với tôi vào thời điểm đó, tôi mong muốn tôi đã không và cuối cùng sẽ quay trở lại và loại bỏ các ràng buộc.

Giống như tôi đã nói, tôi nhận ra tôi là một người mới và nếu có điều gì đó tôi nhìn, hãy cho tôi biết - và cố gắng không để bán thịt tôi quá xấu :) Cảm ơn.

Answer 17

Nó phụ thuộc (trên datatype)

nghĩ về điều này, Nếu công nghệ trực tiếp tương tác với cơ sở dữ liệu là Python tôi sẽ làm cho mọi thứ NOT NULL với một hợp DEFAULT.

Tuy nhiên, điều trên có ý nghĩa nếu cột là VARCHAR với mặc định là chuỗi rỗng.

gì về NUMERIC, Thật khó có thể đưa ra các giá trị mặc định nơi NULL có thể truyền đạt thêm chi tiết khác hơn là chỉ đơn giản là thiết lập để DEFAULT=0

Đối BOOLEAN vẫn NULL làm cho một số ý nghĩa, và vân vân.

Đối số tương tự có thể được thực hiện cho các kiểu dữ liệu khác nhau như các kiểu dữ liệu không gian.