Nous nommons toujours des tables de recherche - telles que des pays, des villes, des régions ... etc - comme ci-dessous: Modifier :
entityName_lk ou lk_entityname (pays_lk ou lk_countries)
Mais je demande si quelqu'un a plus de mieux conversions de nommage pour les tables de recherche?
Nous pensons faire postfix ou préfixe pour résoudre comme un conflit:
Si nous avons utilisateur Tableaux et table de recherche pour USERTypes (nom d'identité) et nous avons une relation beaucoup à plusieurs entre utilisateur et USERTYPES qui fait de nous une table que nous pouvons nommer comme type_for_user qui peut faire une confusion entre Usertypes & type_for_user donc nous aimons Créer une table de recherche userypes comme étant comme UsertyTypesLK pour être évident pour tous
5 Réponses :
Chaque table peut devenir une table de recherche. Considérez qu'une personne est une recherche dans une table de facturation. Donc, à mon avis, les tables ne devraient qu'apporter un nom d'entité (singulier), par ex. Personne, facture.
Ce que vous voulez, c'est une norme pour les noms et contraintes de colonne, tels que P>
Lookups Table | Column | Value
Je veux dire que les tables qui ont presque (nom id) sont toujours faites comme recherche seulement
Mis à jour pour les recherches liées à une table
Vous êtes d'accord 'lk_table' mais je ne comprends pas ce que vous voulez dire par des recherches simples
Si vous avez une liste d'intervalles de date (jour, semaine, quinzaine de jours, mois, biannual, annuel, biennal), c'est une liste de recherche simple. Disons que vous avez une autre liste - Type de paiement: Cash, Eft, Chèque, Commerce. C'est une autre liste simple. Vous pouvez faire une table pour chacun ou je les décolle normalement dans une seule table de recherche avec une clé définissant quel type de recherche ils sont.
Mais cela rendra difficile si vous souhaitez utiliser dans les rapports ou pour faire une relation physique entre table, nous pouvons également faire face à un problème si nous voulons modifier ces données de juste rechercher pour ajouter plus de colonnes ... C'est un meilleur moyen d'utiliser votre chemin pour les valeurs inchangées
Voici deux préoccupations pour savoir s'il faut utiliser un préfixe ou un suffixe.
Dans une liste triée de tables, souhaitez-vous que les tables LK soient ensemble ou souhaitez-vous que toutes les tables relatifs à l'entitéName apparaissent ensemble
Lors de la programmation dans des environnements avec accès automatique, êtes-vous susceptible de taper "LK" pour obtenir la liste des tables ou le début de l'entitéName?
Je pense qu'il y a des arguments pour soit, mais je choisirais de commencer avec l'entitéName.
Pour un environnement complet complet, nous pouvons faire de LK comme Postfix pour éviter d'écrire tout le temps
Il n'y a qu'un seul type de table et je ne crois pas qu'il y ait une bonne raison d'appeler des tables "Recherche" Tables. Utilisez une convention de dénomination qui fonctionne de manière égale à chaque table.
Avant de décider de votre choix, vous devez essayer de comprendre pourquoi vous désignez des tables comme des "recherches" et non des autres. Chaque table doit représenter une entité à elle-même.
Que se passe-t-il lorsqu'une table qui a été désignée comme une "recherche" pousse dans la portée et n'est plus considérée comme une "recherche"? Vous êtes laissé avec changer le nom de la table qui peut être onéreux ou le quitter tel quel et avoir à expliquer à tous qu'une table donnée n'est pas vraiment une «recherche».
Un scénario commun mentionné dans les commentaires liés à une table de jonction. Par exemple, supposons que un utilisateur puisse avoir plusieurs "types" qui sont exprimés dans une table de jonction avec deux clés étrangères. Cette table devrait-elle être appelée user_userypes ? Dans ce scénario, je dirais d'abord que je préfère utiliser le suffixe membre sur la table de jonction. Nous aurions donc utilisateurs , USERTYPES , USERTYPEMBERS . Deuxièmement, le mot "type" dans ce contexte est assez générique. Un Usertype signifie-t-il vraiment un rôle? Le terme que vous utilisez peut faire toute la différence. Si Usertypes sont vraiment des rôles, nos noms de table deviennent utilisateurs , rôles , rolemembers qui semble assez clair.
Que diriez-vous lorsque vous avez une table d'état et que son identifiant est significatif. Dites dans ma candidature, je veux une fonctionnalité de se comporter un certain quand c'est Californie? Si (state.id == (int) lookuppstate.ids.california)
C'est une autre raison de ne pas utiliser une table "de recherche" générique. Un tableau dédié des provinces serait mieux. Techniquement, les abréviations de l'état sont une forme d'un code, alors je nommerais probablement ce "code" PK afin que vous auriez "province.code =" ca "". En règle générale, j'associe l'identifiant de la colonne "ID" avec des touches de substitution plutôt que des codes connus. Le mot "lookup" n'ajoute aucune valeur à votre nommée ici.
une zone où les conventions de nommage de table peuvent aider est la migration de données entre les environnements. Nous devons souvent déplacer des données dans des tables de recherche (qui contraindront des valeurs pouvant apparaître dans d'autres tables) ainsi que des changements de schéma, car ces listes de valeur autorisées changent. Actuellement, nous n'enignons pas les tables de recherche différemment, mais nous envisageons qu'il empêche de demander au gars de migration "quelles tables sont à nouveau des tables de recherche?" à chaque fois.
Les tables de recherche sont en effet valides, types de table spécialisés: "Une table de recherche traite des attributs et de leurs valeurs, pas des entités" de Selko via SIMPLE-TALK.COM/SQL/T-SQL-PROGRAMMING/LOOK-UP-TABLE-IN-SQL -
Pourquoi devez-vous même utiliser un préfixe / postfix spécial pour une table de recherche? Comment distinguer une table de recherche d'une table de données "régulière" ?? Je voudrais simplement utiliser des noms clairs, par ex.
Pays (ouPays ) et être fait avec elle ...Nous faisons le préfixe ou le postfix pour distinguer des tableaux réguliers et des recherches
Dans un projet précédent, nous avons utilisé
lu _ comme préfixe. E.gdbo.lu_glossaire .@ RPM1984, de votre travail, il est préférable d'utiliser le préfixe ou le postfix?
ID aller avec le préfixe, pour le tri et la lisibilité instantanée.
Je suis d'accord avec Marc_s. OMI, vous devriez essayer de comprendre pourquoi vous désignez des tables comme «recherche» et d'autres non. Chaque table doit représenter une entité à elle-même. Si vous utilisez un préfixe ou un suffixe, que se passe-t-il lorsque l'entité "grandit" au-delà d'être une "recherche"? Changer un nom de table est une douleur majeure dans le cul.
@Thomas, s'il vous plaît lire ce que j'écris en modifier pour comprendre pourquoi j'ai besoin de distinguer la table de recherche avec préfixe ou postfix au lieu de noms directs / clairs
@Space Cracker - toujours pas d'accord. Utilisez simplement le suffixe "membre" sur la table de jonction. Donc, vous avez des utilisateurs, des dydictypes, Usertypemembers
@Thomas, "membre" est un moyen de le faire, mais je ne le vois pas lisible et efficace, vous pouvez le remplacer par les utilisateurs_userypes
@Space Cracker - Tout d'abord, je ne suis pas un fan de soulignement des noms d'objet. Ils ont une douleur à taper. Deuxièmement, "efficace" dépend grandement sur son point de vue. Une table nommée "USERTYTYTYS_LOOKUP" qui doit être modifiée à une date ultérieure, car ce n'est pas vraiment une "recherche" (quoi que cela signifie) ou doit garder ce nom même si ce n'est pas une "recherche", est beaucoup moins efficace que de trouver un nom qui représente la relation. Qu'est-ce qu'un "type" utilisateur? Est-ce un rôle? Pourquoi ne pas utiliser les rôles, les utilisateurs, l'USerroles (ou Rolemembership).
@Space Cracker - Si vous utilisez "user_userytypes", que se passe-t-il si vous devez ajouter une autre clé étrangère?
@ Thomas, je suis d'accord avec vous, ce sera un problème si nous ajoutons de nouvelles colonnes qui rendent ce tableau, ce n'est pas un nom de recherche et de changement n'est pas bon et le conserver comme c'est faire son nom non exprès.
@Thomas, si j'ai des "utilisateurs", "USERTYPE" voulez-vous dire que le troisième sera comme «Membre d'USERType '???
@Space Cracker - ou juste Usertypemembers. N'oubliez pas que vous recherchez un nom pour les noms de table. Usertypemembers aurait ustypeid et userid comme clés étrangères. Une autre approche consiste à utiliser le mot "rôle". Ainsi, les utilisateurs, les rôles, les rolémémous où Rolemembers auraient des identifiants et des solides motivés comme des clés étrangères.
@Thomas, merci pour vos réponses et je souhaite résumer tous vos commentaires comme une réponse
@Space Cracker - J'ai ajouté une réponse avec tous les articles que j'ai mentionnés dans les commentaires.