Meilleures pratiques pour les tables de recherche: tables DB ... ou énumérations
Si nous devons stocker les postes disponibles dans une entreprise (ex. Manager, Team Lead, ... etc). Quelles sont les meilleures pratiques pour le stocker? J'ai deux opinions avec commentaires ... "bien sûr, je vous souhaite la bienvenue"
- Le stocker en tant que table DB avec les colonnes ID et Name, et le traiter à l'aide de requêtes et de jointures.
- Le stocker comme Enum et oublier la table DB.
À mon avis, je choisirai la première solution si j'ai des éléments changeants. Pour ne pas coder en dur ces options en Enum.
Je peux choisir la solution Enum, si je ne doute pas que les données ne changeront pas (par exemple, Sexe: Homme, Femme).
REMARQUE: Je code en anglais et la culture de l'interface utilisateur peut être l'arabe. Si je travaille avec la solution Enum, je vais coder en dur les chaînes basées sur la culture dans la couche de présentation, est-ce correct du point de vue des meilleures pratiques !!!!
Je voudrais connaître vos opinions et si mes pensées correspondent à ce qui est le plus recommandé "Best Practices" ??
En règle générale, vous ne devez utiliser l'énumération que s'il existe un ensemble clair d'éléments qui ne changeront pas, par exemple couleurs primaires ou noms de continent. Sinon, les tables de recherche avec des clés étrangères correctement implémentées sont à peu près toujours la meilleure option.
Il existe une variante possible de l'option de table de recherche où vous disposez potentiellement d'un grand nombre de tables de recherche pour des relations id/valeur simples. Une paire domaine/table de recherche peut réduire considérablement le nombre de tables requises, mais avec une complexité de codage supplémentaire. Dans ce cas, vous auriez une table de domaine
DomainID int identité Domaine varchar (255)
et une table clé/valeur
DomainID int ID int identité Valeur varchar (255)
Par conséquent, une ligne est ajoutée à la table de domaine correspondant à chaque table de recherche que vous utiliseriez autrement, et toutes les paires (domaine-clé)/valeur ajoutées à la table de valeur. En plus de simplifier la structure de la base de données, cette approche présente également l'avantage que des "tables de recherche" peuvent être créées dynamiquement dans le code d'application, ce qui, dans certaines applications, peut être extrêmement utile.
Option 1: le stocker en tant que table DB avec les colonnes ID et Name, et les traiter à l'aide de requêtes et de jointures est le minimum que vous devez faire.
De " Cinq erreurs de conception de base de données simples à éviter ":
Bien que l'intégrité appliquée par l'application soit parfois privilégiée par les développeurs, il reste vrai que le SGBD doit toujours être le centralisateur de toutes les intégrités.
La meilleure pratique recommandée consiste à implémenter votre base de données comme si elle ne savait rien de l'interface utilisateur. Autrement dit, la base de données doit appliquer toutes les règles relatives aux données; dans ce cas, la base de données doit appliquer les valeurs appropriées. Pour énumérer les valeurs appropriées, un table de recherche pour chaque type de valeur de recherche est généralement le chemin à parcourir. Plusieurs fois, les applications vont et viennent, mais la base de données reste et est réutilisée.
Si vous souhaitez appliquer des énumérations dans l'application, vous pouvez certainement le faire, mais quoi que vous fassiez, assurez-vous que la base de données fait son travail en tant que base de données et maintient l'intégrité des données. Si c'est gênant, passez par le problème; vous préparez le terrain. Dans " Conception de la base de données et la tour penchée de Pise ", l'écrivain souligne pourquoi il est si important de poser correctement les bases d'une base de données.
J'espère que ça aide.
J'ai tendance à opter pour l'option de base de données car cela permet une interrogation facile avec des données significatives (c'est-à-dire des noms plutôt que des ID).
Si je suis assez confiant que les valeurs ne changeront pas, je les énumérerai également dans l'application car cela facilite le développement lorsque vous n'avez pas à vous souvenir de l'ID d'un élément et rend également le code beaucoup plus lisible.
Cette approche me permet de choisir d'inclure ou non la table de recherche dans les requêtes. Par exemple, je l'inclurais dans une requête de rapport où je souhaite afficher la valeur de recherche, mais je ne peux pas l'inclure lors du chargement de données dans mon application si je peux la déduire de l'énumération à la place.
Évidemment, si les valeurs sont sujettes à changement ou modification, l'énumération peut ne pas être possible.
Vous seul pouvez juger de l'impact de la culture de l'interface utilisateur, je suis certain à 100% de la culture de mes utilisateurs, alors ne vous inquiétez pas trop :).
Je choisis toujours l'option de base de données car elle présente plusieurs avantages, l'un des principaux étant que vous pouvez modifier les noms/descriptions des éléments dans les listes de recherche sans avoir à changer de code. Acceptez également d'avoir une seule table par opposition à beaucoup de petites tables, de cette façon vous codez une seule routine pour récupérer les valeurs de la base de données, ce qui réduit les coûts de maintenance. Avoir une seule routine signifie que vous pouvez investir plus d'efforts pour qu'elle fonctionne bien.
Suite à la réponse de Cruachan ci-dessus, vous pouvez vous en tirer avec une table si vous avez une relation parent-enfant où les lignes sans parent décrivent le domaine. Tous les enregistrements appartenant à un domaine ont la ligne de domaine comme parent.
ID int autonumber -- integer primary key for performance
DomainID int -- null for domains
Name varchar(100) -- Name of the item
Description varchar(255)
Ainsi, par exemple, une liste de devises pourrait contenir:
ID DomainID Name Description
100 NULL ISO Currencies List of ISO Currency codes
101 100 BHD Bahrain Dinar
102 100 GBP British Pound
103 100 EUR Euro
104 100 USD US Dollar
Je préfère généralement les deux. J'utilise la table dans la couche dal car ils peuvent être utilisés pour des outils tels que tableau pour les rapports, les requêtes SQL et autres.
J'utilise des énumérations dans le front-end et la couche métier parce que c'est facile à développer avec eux et vous n'avez pas besoin d'obtenir la liste du dal ni de vous souvenir des valeurs du tableau.
C # convertit automatiquement les énumérations en ID correspondant pour vous si la liste est la même dans la table et l'énumération.
Dans MVC, vous pouvez utiliser la liste déroulante avec les énumérations en tant que @ Html.EnumDropdownListFor () dans la vue afin de ne pas avoir à frapper la base de données elle-même pour les listes déroulantes.
J'ai tendance à toujours mettre ce genre de choses dans une table. S'il en faut beaucoup, je le cache. Si j'ai besoin de faire référence par programmation à certains d'entre eux, je vais ensuite créer une énumération dont les valeurs sont définies sur la valeur clé de l'élément de recherche.
Par exemple, une clé primaire de substitution (généralement pour que ma couche d'accès aux données puisse l'ajouter/la mettre à jour), un champ pour la valeur de l'élément, plus un "candidat" (le candidat étant entre guillemets car ce n'est pas obligatoire, il est donc unique) ou null). De cette façon, je peux utiliser l'énumération entre guillemets pour faire référence à des éléments spécifiques/importants dans le tableau, mais j'ai toujours la possibilité de laisser les utilisateurs finaux ajouter de nouveaux éléments. Les spécificités du modèle de données utilisé dépendent vraiment de vos préférences (certaines personnes peuvent me crier dessus en ce moment pour ne pas simplement utiliser le champ "candidat" comme vraie clé primaire).
La seule chose que vous envisagez de mettre dans un db cette liste d'employeurs?
Si oui, déposez-le dans un fichier et terminez-le.
Les bases de données sont excellentes, mais si vous avez besoin d'une valeur-clé simple, elles sont excessives. Ils vous donnent beaucoup de choses. Mais ils font aussi beaucoup de choses dans les coulisses, c'est une chose de plus que vous devez prendre en charge ... si vous pouvez vous en sortir avec un seul fichier avec 20 lignes délimitées par des tabulations, optez pour la simplicité.
Si vous avez beaucoup de choses qui nécessitent ces types de recherches, ou si vous pensez que vous pourriez avoir besoin de les mettre à jour pendant qu'un client essaie de les lire, ou si vous souhaitez faire des références croisées plus tard - alors allez-y pour la DB.
Recherches, recherches, recherches (insérer ici une vidéo de danse de singe)
Ma personnelle "meilleure pratique" est d'avoir tout dans la base de données. Les postes dans une entreprise sont définitivement une table de correspondance.
Il en va de même pour les traductions, ce qui peut être un peu plus délicat, mais généralement une définition de vue joignant la table à une table de traduction est un bon début.
En outre, si la position est uniquement une valeur int et que votre application est en une seule langue, vous pouvez ajouter les titres de position directement à la base de données.
Si vous pouvez les garder synchronisés, je ne pense pas qu'il y ait beaucoup de raisons de ne pas avoir les deux. Lorsque je développais certaines fonctionnalités de la machine à états avec un magasin de bases de données, cela facilitait considérablement l'énumération des états d'objet disponibles dans mon IDE.
Je me suis écrit un petit complément EnumGenerator Visual Studio il y a quelque temps qui crée un extrait de code d'énumération en C # à partir des colonnes ID et DESC d'une tablette DB que vous sélectionnez directement dans l'IDE. Je ne l'ai pas publié parce que c'était la première fois que je travaillais avec VS Addins et c'était assez junky mais je parie que quelqu'un avec une expérience de génération de complément/code pourrait prendre l'idée et courir avec.