Alcune persone cercano di evitare NULL valori, affermare che la logica sarebbe fonte di confusione.
Non sono uno di loro. NULL i valori vanno bene per le colonne senza dati. Sono sicuramente il modo più economico per archiviare colonne "vuote", sia per lo spazio su disco che per le prestazioni (l'effetto principale sono tabelle e indici più piccoli):
- Non si utilizza NULL in PostgreSQL utilizza ancora una bitmap NULL nell'intestazione?
- L'impostazione "NOT NULL" su una colonna in postgresql aumenta le prestazioni?
- Le colonne nullable occupano spazio aggiuntivo in PostgreSQL?
Una volta che capisci la natura di NULL valori, non c'è motivo per evitarli. Postgres offre una varietà di funzioni per gestire i NULL. colaesce()
, nullif()
, concat() , concat_ws()
, ...
In generale, per quanto riguarda il rendimento è interessato, un vincolo NOT NULL supera un vincolo CHECK ed entrambi battono trigger da un log shot. Ma anche i trigger semplici sono economici. Il costo di un NOT NULL il vincolo è quasi nulla. Inoltre, tutti questi influiscono solo sulle operazioni di scrittura, ma nella maggior parte delle applicazioni dominano le operazioni di lettura.
L'impatto più rilevante sulla performance (indici e query non ottimali a parte) è quindi la dimensione di tabelle e indici o, soprattutto, il numero di tuple per pagina di dati . Tuple più grandi portano a prestazioni più lente per la maggior parte dei casi d'uso. Il numero di pagine di dati che devono essere lette per soddisfare una query aumenta di conseguenza. La memoria cache disponibile è stata saturata prima.
Non ho un benchmark pronto, ma è comunque meglio testare per il tuo particolare ambiente. Queste sono solo semplici regole pratiche. La realtà è molto più complessa.
