Vous vous débattez avec le partitionnement vertical. Il s'agit d'une technique de conception de base de données physique destinée à améliorer les performances. Comme pour toute technique de conception de base de données physique, son applicabilité dépend des requêtes spécifiques que vous tentez d'optimiser et du potentiel de cette technique pour les optimiser. D'un point de vue logique, si ces nouveaux champs dépendent de la clé candidate de votre entité, ce sont des faits la concernant qui lui appartiennent. Tout d’abord, vous devez vous assurer de bien comprendre la dépendance fonctionnelle de ces nouveaux champs sur les clés de votre candidat afin de vous assurer qu’il s’agit bien de faits sur les pages vues quotidiennement. Si tel est le cas, décider de les partitionner dans une autre table constitue une optimisation des performances qui ne doit être effectuée que si elle atteint vos objectifs de performance.
En général, le partitionnement vertical est utile si vous souhaitez interroger ces nouvelles colonnes de manière peu fréquente et distincte des autres colonnes de la table d'origine. En plaçant ces colonnes dans une autre table partageant le même PK que votre table existante, vous pouvez l'interroger directement lorsque vous voulez ces nouvelles colonnes et obtenir un rendement beaucoup plus important, car vous disposerez de beaucoup plus de lignes par page sur le disque pour cette nouvelle table. comme toutes les colonnes de la table d'origine ne seront pas assis sur ces lignes. Cependant, si vous interrogez toujours ces colonnes avec les colonnes de la table d'origine, une partition verticale n'aurait pas beaucoup de sens car vous devrez toujours faire une jointure externe pour les obtenir. Les pages des tables sur disque entrent dans le pool de mémoire tampon d’un SGBD indépendamment, jamais pré-jointes, et donc cette jointure devra avoir lieu à chaque exécution de requête même si les données sont épinglées dans le pool de mémoire tampon. Dans ce scénario, les colonnes NULLABLE de la table d'origine permettraient au moteur de stockage de SGBD de les stocker efficacement lorsque NULL, ce qui éliminerait le besoin de rejoindre la récupération.
Il me semble que votre cas d'utilisation est le dernier et l'ajout de NULLABLE à votre table d'origine est la voie à suivre. Mais, comme pour tout ce qui concerne la conception des bases de données, cela dépend. Pour pouvoir prendre la bonne décision, vous devez connaître la charge de travail attendue et définir le choix. Un panneau de recherche de personnes constitue un bon exemple d'utilisation d'un partitionnement vertical. Votre application contient des informations très rarement renseignées sur une personne sur laquelle une personne peut souhaiter effectuer une recherche, mais le fait rarement. Si vous mettez ces informations dans une autre table, vous disposez de bonnes options en termes de performances. Vous pouvez écrire la recherche de manière à ce que vous ayez 2 requêtes - une qui utilise uniquement les informations principales, toujours renseignées (comme le nom de famille ou ssn), et un autre qui joint les informations très rarement renseignées uniquement lorsque la recherche est demandée. Vous pouvez également tirer parti de l'optimiseur de SGBD s'il est suffisamment intelligent pour reconnaître, pour un ensemble de variables hôte donné, que la jointure externe n'est pas nécessaire et ne l'exécutera pas. Vous ne devez donc créer qu'une requête.
Quelle plateforme de SGBD utilisez-vous? La manière dont la plate-forme gère le stockage des colonnes NULL, optimise votre requête ainsi que la disponibilité de la prise en charge des colonnes fragmentées (SQL Server l’a) a une incidence sur la décision. En fin de compte, je vous recommanderais d'essayer les deux conceptions dans un environnement de test avec des données et une charge de travail de la taille de la production, et de déterminer lequel correspond le mieux à vos objectifs de performance.