Saya memiliki aplikasi (data disimpan dalam PostgreSQL), di mana sebagian besar bidang dalam tabel selalu tidak nol, tetapi skema untuk tabel ini tidak memberlakukan ini. Sebagai contoh, lihat tabel palsu ini:

CREATE TABLE "tbl" (
    "id" serial,
    "name" varchar(40),
    "num" int,
    "time" timestamp
    PRIMARY KEY ("id"),
    UNIQUE ("id")
);

Juga name, num, timetidak secara eksplisit dinyatakan sebagai NOT NULL, dalam kenyataannya mereka, karena penegakan terjadi di sisi aplikasi.

Perasaan saya adalah bahwa itu harus diubah, tetapi sebaliknya adalah bahwa tingkat aplikasi memastikan bahwa nilai nol tidak dapat muncul di sini dan tidak ada orang lain yang secara manual memodifikasi tabel.

Pertanyaan saya adalah : Apa manfaatnya (kinerja, penyimpanan, konsistensi, sesuatu yang lain) dan kelemahannya (dengan asumsi saya sudah memverifikasi bahwa tidak ada null yang ada saat ini, dan dari logika bisnis seharusnya tidak ada null) dengan menetapkan NOT NULLkendala eksplisit ?

Kami memiliki proses peninjauan kode yang baik dan dokumentasi yang cukup baik, sehingga kemungkinan bahwa beberapa orang baru akan melakukan sesuatu yang melanggar batasan ini tidak benar-benar cukup untuk membenarkan perubahan.

Ini bukan keputusan saya, jadi inilah tepatnya mengapa saya mencari pembenaran lain. Menurut pendapat saya, jika sesuatu tidak bisa menjadi nol dan database memungkinkan Anda menentukan bahwa sesuatu itu bukan nol - maka lakukan saja. Apalagi jika ubahannya super sederhana.

Apa yang terjadi ketika seorang programmer baru tiba dan harus menulis aplikasi terhadap db itu? Mereka tidak tahu bidang x itu seharusnya NOT NULL.

Program lain mungkin berasumsi bahwa semua bidang x adalah NOT NULLuntuk melakukan penghitungan katakan, tetapi beberapa sekarang adalah NULLkarena program baru, yang mengarah ke kesalahan yang tidak konsisten dan sulit dilacak.

IMHO itu selalu yang terbaik untuk menegakkan aturan integritas data sedekat mungkin dengan data, yaitu dalam database. Dengan begitu, aplikasi dan / atau programmer baru tidak dapat mengacaukan data Anda.

Pemrogram, aplikasi, bahasa dan kerangka kerja datang dan pergi. Data dan basis data cenderung bertahan. Basis data adalah garis pertahanan terakhir Anda terhadap data yang tidak konsisten dan berpotensi salah.

Manfaatkan secara maksimal mekanisme penegakan kendala integritas database Anda, bahkan dengan mengorbankan kinerja. Sistem lambat yang menghasilkan hasil yang benar jauh lebih unggul daripada yang cepat yang salah!

Seperti yang sudah dikutip oleh orang lain dalam komentar, menambahkan NOT NULLspesifikasi tabel Anda dapat meningkatkan kinerja kueri Anda secara signifikan (selain alasan metodologi yang sangat baik yang dinyatakan dalam jawaban lain).

Alasannya adalah bahwa optimizer kueri, mengetahui bahwa kolom tidak dapat memiliki NULLnilai, dapat mengecualikan pengujian khusus untuk nilai-nilai tersebut, seperti dalam kasus NOT INvs. NOT EXISTSMisalnya , Anda dapat melihat blog ini , yang menunjukkan bahwa tidak mendeklarasikan bidang NOT NULL(saat tabel berisi selalu nilai-nilai bukan nol) dengan kueri tertentu meningkatkan waktu pelaksanaan 500%. Hasilnya ditampilkan untuk SQL Server, tetapi perilaku serupa dapat hadir dalam DBMS relasional lainnya, seperti milik Anda (belum lagi fakta bahwa database Anda dapat diangkut ke sistem lain). Aturan umum yang dapat Anda asumsikan adalah bahwa ketika lebih banyak informasi tersedia untuk optimizer kueri, maka rencana akses yang lebih efisien dapat dihasilkan.

Implikasi ruang

The implikasi ruang dibicarakan di posting ini dengan @Erwin Brandstetter

Singkatnya, Anda akan menyimpan satu totalColumns - 8bit yang dibulatkan ke byte terdekat (atau MAXALIGN), jika database Anda memiliki

1. Lebih dari 8 kolom
2. SEMUA kolom di atas adalahNOT NULL

Implikasi kinerja

Namun, dalam posting ini di SE oleh @Erwin Brandstetter , katanya

1. "Pengaturan NOT NULL tidak memiliki efek pada kinerja. Beberapa siklus untuk pemeriksaan - tidak relevan."
2. "... dengan menggunakan NULLs alih-alih nilai dummy. Tergantung pada tipe data, kamu dapat menghemat banyak ruang disk dan RAM, dengan demikian mempercepat .. semuanya."

@Renzo memiliki jawaban yang berbicara tentang implikasi kinerja - saya akan menganggap tidak ada yang berlaku untuk PostgreSQL . Saya tidak dapat menemukan apa pun yang mendukung semua itu sebagai relevan dengan PostgreSQL. Siklus apa pun yang disimpan tidak dapat dikuantifikasi bahkan dalam kueri yang paling mendasar sekalipun.

CREATE TABLE foo (
  a int,
  b int NOT NULL,
  x float,
  y float NOT NULL
);

INSERT INTO foo ( a, b, x, y )
SELECT x, x, x, x
FROM generate_series(1,1E7) AS X(x);

EXPLAIN ANALYZE SELECT 1/a FROM foo;
EXPLAIN ANALYZE SELECT 1/b FROM foo;
EXPLAIN ANALYZE SELECT 1/x FROM foo;
EXPLAIN ANALYZE SELECT 1/y FROM foo;

Selain itu saya menjalankan beberapa tes untuk melihat apakah NULL-indeks lebih cepat, dan saya tidak bisa membuktikannya. Anda dapat menemukan utas yang sangat berguna ini oleh Scott Marlowe di milis yang berbicara tentang perencana kueri di 9.1 yang dapat menggunakan indeks parsial pada klausa WHERE yang berbeda. Saya menguji ini dengan menjalankan yang berikut ini

CREATE TABLE foo ( a int );
CREATE TABLE bar ( a int NOT NULL );
INSERT INTO foo
  SELECT null FROM generate_series(1,1e5) AS x
  UNION ALL
  SELECT 10
  UNION ALL
  SELECT null FROM generate_series(1,1e5) AS x
;
INSERT INTO bar
  SELECT 0 FROM generate_series(1,1e5) AS x
  UNION ALL
  SELECT 10
  UNION ALL
  SELECT 0 FROM generate_series(1,1e5) AS x
;

Sekarang saya membuat indeks,

CREATE INDEX foobar ON foo(a) WHERE a IS NOT NULL;
CREATE INDEX barbar ON bar(a) WHERE a <> 0;

Dalam kedua kasus ini perencana dapat menggunakan indeks saat memilih = 10dan menggunakan pemindaian seq saat mencari masing-masing NULL atau 0. Kedua indeks parsial memiliki ukuran yang sama. Dan, indeks lengkap (tidak ditampilkan) memiliki ukuran yang sama. Mengikuti metodologi yang sama saya memuat tabel dengan satu urutan 1..1e5, dan satu nilai nol / 0, dan urutan lain dari 1..1e5. Kedua metode dapat menemukan nol / 0 dengan indeks yang mencakup seluruh tabel.

TLDR; Ringkasan

Saya tidak dapat membuktikan sesuatu dengan cara apa pun pada sebagian besar masalah kinerja yang saya pikir layak untuk diuji termasuk ketidakcukupan perencana. Manfaat menggunakan null untuk menghemat ram adalah nyata. Ruang disk yang disimpan dengan tidak menggunakan null dapat diabaikan, dan itu terlalu berlebihan pada tabel dengan satu NULLABLEkolom, atau kurang dari 8 kolom. Dalam kasus tersebut tidak ada ruang disk yang disimpan.