Certaines personnes essaient d'éviter NULL affirmer que la logique serait déroutante.
Je ne suis pas l'un d'entre eux. NULL les valeurs conviennent parfaitement aux colonnes sans données. Ils sont certainement le moyen le moins cher de stocker des colonnes "vides" - pour l'espace disque ainsi que pour les performances (l'effet principal étant des tables et des index plus petits) :
- L'utilisation de NULL dans PostgreSQL n'utilise-t-elle pas toujours un bitmap NULL dans l'en-tête ?
- La définition de "NOT NULL" sur une colonne dans postgresql augmente-t-elle les performances ?
- Les colonnes nullables occupent-elles de l'espace supplémentaire dans PostgreSQL ?
Une fois que vous avez compris la nature de NULL valeurs, il n'y a aucune raison de les éviter. Postgres offre une variété de fonctions pour gérer les NULL. colaesce()
, nullif()
, concat() , concat_ws()
, ...
Généralement, en ce qui concerne les performances est concerné, une contrainte NOT NULL dépasse une contrainte CHECK et les deux battent les déclencheurs par un coup de bûche. Mais même les déclencheurs simples sont bon marché. Le coût d'un NOT NULL la contrainte est presque nulle. En outre, tous ces éléments n'affectent que les opérations d'écriture, mais dans la plupart des applications, les opérations de lecture dominent.
L'impact le plus pertinent sur les performances (indices et requêtes sous-optimaux mis à part) est donc la taille de tables et d'index ou, plus important encore, le nombre de tuples par page de données . Des tuples plus gros entraînent des performances plus lentes pour la plupart des cas d'utilisation. Le nombre de pages de données qui doivent être lues pour satisfaire une requête augmente en conséquence. La mémoire cache disponible est saturée plus tôt.
Je n'ai pas de référence prête, mais il est préférable de tester votre environnement particulier de toute façon. Ce ne sont que des règles simples. La réalité est beaucoup plus complexe.
