Quand envisager les tableaux de référence?

Aug 26 2020

En pensant à une application. Disons les détails d'un utilisateur d'applications.

Disons que l'application permet à un utilisateur de modifier facilement son profil.

Pour un champ comme le sexe, qui dans la plupart des cas sera marqué MF ou autre. Si ces valeurs doivent être stockées dans une table de référence par exemple.

Et ma question fondamentale est la suivante: quand commencez-vous à rendre votre application presque trop impliquée avec un schéma comme un schéma Star qui finit par ne pas être aussi utile pour les transactions rapides?

Je m'inquiète simplement lorsque vous commencez à tout décomposer en faits et en dimensions, nous nous retrouvons avec une base de données de rapports avec laquelle une application peut ne pas fonctionner aussi efficacement.

Réponses

3 Christophe Aug 26 2020 at 17:30

Tout est une question d'intention et d'équilibre. A vous de prendre votre décision.

Si vous mettez des Gendervaleurs dans une table de référence, vous bénéficiez des avantages suivants:

personnalisation facile des valeurs;
localisation facile de votre code dans d'autres langues;
extension relativement facile des valeurs possibles;
uniformisation / généréricité des requêtes et de la présentation: vous utilisez la même approche pour chaque table de référence.

De plus, si ce Gendern'est que descriptif et sans impact sur le comportement de l'application, vous n'aurez plus à vous soucier des valeurs possibles, et même pas besoin d'une énumération, obtenant un système très flexible. En revanche, si vous avez un comportement spécifique pour certaines valeurs, vous n'aurez qu'une flexibilité partielle.

Si vous ne mettez pas Genderdans un tableau de référence, vous bénéficiez des avantages suivants:

un meilleur contrôle sur les valeurs autorisées et les comportements associés,
quelques octets de table de référence enregistrés (mais à la taille d'une base de données, cela ne fera aucune différence)
performances accrues, évitant une jointure (cela s'applique aux bases de données NoSql où la jointure peut nécessiter une extraction supplémentaire; ce n'est pas un argument pour un SGBDR, où l'optimiseur trouverait de toute façon le caractère de référence et mettrait en cache les données pour faire la jointure sans aucun frais généraux importants)
flexibilité accrue pour la présentation, lorsque la valeur affichée peut être générée (surtout si votre langue autorise des valeurs associées comme swift)

D'après ma propre expérience, la première approche s'est avérée très utile pour simplifier le code et la réutilisation du code. Mais je peux imaginer que la deuxième approche pourrait l'emporter sur ces avantages dans certaines circonstances (en particulier dans un contexte nosql).

Je préfère ne pas répondre à la question plus générale sur le schéma en étoile, car cela dépend beaucoup des dbms sous-jacents, mais aussi des modèles d'accès, et en plus des modèles d'écriture; de plus l'étoile avec des tableaux non référencés peut être incontournable en fonction des besoins.

1 GregBurghardt Aug 26 2020 at 19:47

Je penche vers les tables de référence dans une base de données relationnelle pour une raison très simple: le "C" dans ACID .

La cohérence est bénéfique, non seulement pour les programmeurs, mais également pour les utilisateurs. J'ai travaillé dans des bases de données où des champs comme celui-ci n'étaient que du texte. L'interface utilisateur affichait une liste déroulante ou un groupe de boutons radio, ce qui la faisait apparaître comme une énumération, mais au niveau des données, il s'agissait simplement de texte ouvert. Au fil du temps, la liste des valeurs a changé, mais les anciens enregistrements n'ont pas été mis à jour. Les gens construisaient des rapports et des requêtes de base de données ad hoc dans l'espoir de trouver un enregistrement qui est accidentellement filtré parce qu'il s'agissait d'un ancien enregistrement avec une valeur qui n'était plus présentée sur l'interface utilisateur. Cela peut être ennuyeux, pouvant aller jusqu'à une erreur fatale dans le code de l'application si une programmation défensive appropriée n'existe pas dans le code.

Les tableaux de références doivent comprendre au moins 7 colonnes:

Clé primaire (string ou int, mais je préfère string dans ce cas)
Date à laquelle cet enregistrement est devenu un choix valide
Date à laquelle cet enregistrement a été abandonné
Qui a créé le disque
Quand il a été créé
Qui a mis à jour l'enregistrement pour la dernière fois
Quand il a été mis à jour pour la dernière fois

Une colonne "description" facultative peut être un bon moyen d'enregistrer la raison pour laquelle l'enregistrement a été créé en premier lieu.

Les clés étrangères d'autres tables vers la table de référence garantissent que votre énumération dans le niveau application a une représentation valide dans le niveau données. Les dates de début et de fin de chaque enregistrement indiquent clairement si chacune de ces valeurs d'énumération est actuellement utilisée ou si elles sont obsolètes. Cela aide lors de la création de rapports ou de requêtes SQL ad hoc, car vous savez que vous avez un enregistrement dans une table avec une sorte d'informations supplémentaires sur l'utilisation professionnelle de cet enregistrement.

N'oubliez pas que les choses changent. Les hommes et les femmes semblent être des concepts assez solides, mais les normes sociales changent. Ce qui était autrefois considéré comme un choix binaire se développe dans certains pays et cultures. De nouvelles valeurs pourraient être ajoutées. Les anciennes valeurs peuvent être obsolètes. Un tableau de référence vous permet de restreindre vos choix actuels, ainsi que de conserver un historique des choix passés qui étaient valides, mais qui ne le sont plus.

Addendum: Pour faire du genre un concept encore plus déroutant, chaque personne peut s'identifier à plusieurs genres à la fois. Les domaines médicaux doivent savoir avec quel sexe vous êtes né, car cela peut faire une différence dans les soins médicaux. D'autres cas d'utilisation peuvent simplement avoir besoin de connaître une préférence.