Ho un'applicazione (i dati sono archiviati in PostgreSQL), dove la maggior parte dei campi nelle tabelle non è sempre nulla, ma lo schema per queste tabelle non lo applica. Ad esempio guarda questo falso tavolo:

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

Inoltre name, num, timenon sono esplicitamente dichiarato come NOT NULL, in realtà sono, perché l'esecuzione avviene sul lato di applicazione.

La mia sensazione è che dovrebbe essere cambiato, ma il contrappunto è che il livello dell'applicazione si assicura che i valori null non possano apparire qui e nessun altro modifica manualmente la tabella.

La mia domanda è : quali sono i vantaggi (prestazioni, archiviazione, coerenza, qualcos'altro) e gli svantaggi (supponendo che ho già verificato che al momento non siano presenti null e che dalla logica aziendale non dovrebbero esserci null) impostando un NOT NULLvincolo esplicito ?

Abbiamo un buon processo di revisione del codice e una documentazione ragionevolmente buona, quindi la possibilità che una persona nuova commetterebbe qualcosa che rompa questo vincolo non è davvero sufficiente per giustificare il cambiamento.

Questa non è una mia decisione, quindi è esattamente per questo che cerco altre giustificazioni. Secondo me, se qualcosa non può essere nullo e un database ti consente di specificare che qualcosa non è null, allora fallo. Soprattutto se il cambiamento è super semplice.

Cosa succede quando arriva un nuovo programmatore e deve scrivere un'app contro quel db? Non sanno che il campo x deve essere NOT NULL.

Un altro programma potrebbe supporre che tutti i campi x siano NOT NULLper eseguire conteggi, ma alcuni ora sono a NULLcausa del nuovo programma, portando a errori incoerenti e difficili da rintracciare.

IMHO è sempre meglio applicare le regole di integrità dei dati il ​​più vicino possibile ai dati, cioè nel database. In questo modo, nuove app e / o programmatori non possono confondere i tuoi dati.

Programmatori, applicazioni, lingue e framework vanno e vengono. Dati e database tendono a persistere. Il database è la tua ultima linea di difesa contro dati incoerenti, potenzialmente errati.

Sfruttare al massimo i meccanismi di imposizione dei vincoli di integrità del database, anche a spese delle prestazioni. Un sistema lento che produce risultati corretti è infinitamente superiore a uno veloce che sbaglia le cose!

Come già citato da altri nei commenti, l'aggiunta NOT NULLalle specifiche della tabella può migliorare in modo significativo le prestazioni delle query (oltre alle ottime ragioni metodologiche indicate in un'altra risposta).

Il motivo è che Query Optimizer, sapendo che una colonna non può avere un NULLvalore, può escludere test speciali per tali valori, come nel caso NOT INvs. NOT EXISTSAd esempio, puoi vedere questo blog , dove viene mostrato che non dichiarare un campo NOT NULL(quando la tabella contiene sempre valori non nulli) con una certa query aumenta il tempo di esecuzione del 500%. Il risultato è mostrato per SQL Server, ma un comportamento simile potrebbe essere presente in altri DBMS relazionali, come il tuo (per non parlare del fatto che il tuo database potrebbe essere portato su altri sistemi). Una regola generale che si può presumere è che quando più informazioni sono disponibili per Query Optimizer, è possibile produrre piani di accesso più efficienti.

Implicazioni spaziali

Le implicazioni spaziali sono discusse in questo post da @Erwin Brandstetter

In breve, si salverà un totalColumns - 8bit arrotondato per eccesso al byte (o MAXALIGN) più vicino , se il database ha

1. Più di 8 colonne
2. TUTTE le colonne sul tavolo sonoNOT NULL

Implicazioni sulle prestazioni

Tuttavia, in questo post su SE di @Erwin Brandstetter , afferma

1. "L'impostazione di NOT NULL non ha alcun effetto di per sé sulle prestazioni. Alcuni cicli per il controllo - irrilevante."
2. "... utilizzando effettivamente i NULL anziché i valori fittizi. A seconda dei tipi di dati, puoi risparmiare molto spazio su disco e RAM, velocizzando così ... tutto."

@Renzo ha una risposta che parla delle implicazioni delle prestazioni - suppongo che nulla di tutto ciò sia applicabile a PostgreSQL . Non trovo nulla che sostenga nulla di ciò come rilevante per PostgreSQL. Qualunque ciclo venga salvato, non può essere quantificato nemmeno nella query più rudimentale.

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;

Inoltre ho eseguito alcuni test per vedere se gli indici NULL fossero mai più veloci e non sono riuscito a confermarlo. Puoi trovare questo thread incredibilmente utile di Scott Marlowe nelle mailing list che parlano del pianificatore di query in 9.1 in grado di usare un indice parziale su clausole WHERE diverse. Ho provato questo eseguendo il seguente

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
;

Ora ho creato gli indici,

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

In entrambi questi casi il planner è stato in grado di utilizzare l'indice durante la selezione = 10e ha utilizzato una scansione seq durante la ricerca di NULL o 0 rispettivamente. Entrambi gli indici parziali avevano le stesse dimensioni. E gli indici completi (non mostrati) avevano le stesse dimensioni. Seguendo la stessa metodologia ho caricato la tabella con una sequenza di 1..1e5, un valore null / 0 e un'altra sequenza di 1..1e5. Entrambi i metodi sono stati in grado di trovare null / 0 con un indice che copre l'intera tabella.

TLDR; Sommario

Non posso dimostrare nulla in un modo o nell'altro sulla maggior parte delle preoccupazioni relative alle prestazioni che pensavo valessero la pena testare per includere l'insufficienza del pianificatore. Il vantaggio di usare null per salvare ram è reale. Lo spazio su disco risparmiato non utilizzando null è trascurabile e si tratta di un'esagerazione eccessiva su tabelle con una NULLABLEcolonna o meno di 8 colonne. In questi casi non c'è spazio su disco risparmiato.