En supposant que nous parlons de relations 1: 1 entre toutes les tables.
Le stockage global est pratiquement toujours (substantiellement) moins cher avec une seule table au lieu de plusieurs tables dans une relation 1: 1. Chaque ligne a 28 octets de surcharge, plus généralement quelques octets supplémentaires pour un remplissage supplémentaire. Et vous devez stocker la colonne PK avec chaque table. Et avoir un index séparé (redondant) sur chacune de ces colonnes ... La taille est importante pour les performances.
Cela est même vrai si de nombreuses colonnes sont NULL dans la plupart des lignes car le stockage NULL est très bon marché :
Lors de la récupération de toutes les colonnes, une seule table est sensiblement plus rapide que 5 tables réunies. C'est aussi beaucoup plus simple . Cinq tables peuvent être difficiles à joindre si toutes les lignes ne sont pas présentes dans toutes les tables. Avec des WHERE
conditions ciblant une seule table, il est assez facile d'ajouter d'autres tables avec LEFT JOIN
. Pas aussi banal si vous avez des prédicats sur plusieurs tables ...
Le partitionnement vertical peut encore améliorer les performances de certaines requêtes. Par exemple, si 90% de vos requêtes récupèrent les mêmes 5 colonnes sur les 65 disponibles, ce serait plus rapide avec une table contenant uniquement ces 5 colonnes.
OTOH, vous pourriez être en mesure de répondre à de telles requêtes sur quelques colonnes sélectionnées avec un index «couvrant» permettant des analyses d'index uniquement .
Un autre candidat pour le partitionnement vertical: si vous avez beaucoup de mises à jour sur seulement quelques colonnes, alors que le reste ne change presque jamais. Dans un tel cas, il pourrait être considérablement moins coûteux de diviser des lignes, car Postgres écrit une nouvelle version de ligne pour chaque mise à jour. Il existe des exceptions pour les grandes valeurs stockées hors ligne ("TOASTed"). Plus de détails:
Cela dépend vraiment de la situation complète. En cas de doute, optez pour la solution simple d'avoir une seule table, surtout si elle représente bien la réalité: dans votre exemple, ce sont tous des attributs d'une voiture et ont du sens ensemble.
VehicleInterior
, d' autres requêtes qui traitent avec des colonnes de seulementVehicleTechnical
, etc. Ou s'il y a beaucoup de lignes / véhicules qui ne sont absolument pas d' info au sujet (par exemple)VehicleExtra
si au lieu de plusieurs lignes avec beaucoup de valeurs nulles dans la même table, vous avez des lignes dans le reste des tables et aucune ligne dansVehicleExtra