Einige Leute versuchen, NULL zu vermeiden Werten, wäre es verwirrend, die Logik zu behaupten.
Ich bin keiner von ihnen. NULL Werte sind für Spalten ohne Daten in Ordnung. Sie sind sicherlich die billigste Möglichkeit, "leere" Spalten zu speichern - sowohl für den Speicherplatz als auch für die Leistung (der Haupteffekt sind kleinere Tabellen und Indizes):
- Verwendet die Verwendung von NULL in PostgreSQL nicht immer noch eine NULL-Bitmap im Header?
- Erhöht die Einstellung "NOT NULL" für eine Spalte in postgresql die Leistung?
- Nullbare Spalten belegen zusätzlichen Platz in PostgreSQL?
Sobald Sie verstehen die Natur von NULL Werte, es gibt keinen Grund, sie zu vermeiden. Postgres bietet eine Vielzahl von Funktionen, um mit NULLs umzugehen. colaesce()
, nullif()
, concat() , concat_ws()
, ...
Im Allgemeinen, was die Leistung betrifft betrifft, eine NOT NULL-Einschränkung schlägt eine CHECK-Einschränkung und beide schlagen Trigger durch einen Logshot. Aber auch einfache Trigger sind billig. Die Kosten für NOT NULL Einschränkung ist so gut wie nichts. Außerdem wirken sich all diese nur auf Schreiboperationen aus, aber in den meisten Anwendungen dominieren Leseoperationen.
Die relevanteste Auswirkung auf die Leistung (abgesehen von suboptimalen Indizes und Abfragen) ist daher die Größe von Tabellen und Indizes oder, noch wichtiger, die Anzahl der Tupel pro Datenseite . Größere Tupel führen in den meisten Anwendungsfällen zu einer langsameren Leistung. Die Anzahl der Datenseiten, die gelesen werden müssen, um eine Anfrage zu erfüllen, steigt entsprechend an. Der verfügbare Cache-Speicher ist früher gesättigt.
Ich habe keinen Benchmark bereit, aber es ist am besten, trotzdem für Ihre spezielle Umgebung zu testen. Das sind nur einfache Faustregeln. Die Realität ist viel komplexer.
