Là một sinh viên CS, tôi đã học được một số lượng lớn các ngôn ngữ lập trình trong nhiều năm qua, hầu hết trong số đó có một số khái niệm về loại "không thể" hoặc "tùy chọn". Lưu ý rằng tôi không nói về các con trỏ hoặc tham chiếu null hoặc các ngôn ngữ được gõ yếu như JavaScript, nơi mọi thứ đều có thể null. Ví dụ về những gì tôi đang nói đến bao gồm boost::optional(C ++), java.util.Optional(Java 8.0), prelude.Maybe(Haskell) và tất cả các '?' loại (ví dụ int?, float?, C # và Kotlin). Đây là các cấu trúc thêm nullable vào một loại không nullable trước đây trong một hệ thống loại tĩnh, nghiêm ngặt.
SQL có một khái niệm tương tự: một loại như INTEGERcó thể được tạo thành nullable hoặc không nullable - nhưng có một sự thay đổi. Trong SQL, không thể INTEGERrỗng theo mặc định và phải được viết rõ ràng như INTEGER NOT NULLlà không thể rỗng.
Nó gây cho tôi sự phản cảm và cực kỳ nguy hiểm khi cho phép NULL trở thành hành vi mặc định. Rõ ràng SQL đã xuất hiện từ rất lâu tại thời điểm này (hầu hết) các nhà phát triển SQL đã phát triển nhận thức lành mạnh về những cạm bẫy của NULL. Nhưng tôi không thể không tưởng tượng rằng trong những ngày đầu, NULL thường xuất hiện ở những nơi không ngờ tới và có vấn đề.
SQL có trước tất cả các ví dụ tôi đã cung cấp, vì vậy có thể đây đơn giản là vấn đề cho sự tiến hóa lịch sử. Tuy nhiên, tôi phải hỏi, liệu có lý do chính đáng nào để ngôn ngữ được thiết kế theo cách này, với các loại là không thể mặc định?
Nếu vậy, nó chỉ là một lý do lịch sử, hay logic giữ vững thiết kế cơ sở dữ liệu ngày nay?
Chỉnh sửa: Tôi không hỏi tại sao NULL là một phần của SQL hoặc tại sao các cột không thể hữu ích. Tôi chỉ hỏi tại sao cột là nullable theo mặc định . Ví dụ, tại sao chúng ta viết:
column1 FLOAT,
column2 FLOAT NOT NULLThay vì:
column1 FLOAT NULLABLE,
column2 FLOAT