Je viens de donner un schéma de base de données pour une base de données que j'ai créée à notre responsable de la base de données et elle a mis un tas de notes suggérant que je renomme certaines tables, il est donc clair que ce sont des tables de recherche (ajoutez "lu" au début du tableau Nom).
Mon problème est que ceux-ci ne correspondent pas à la définition de ce que je considère être une table de recherche. J'ai toujours considéré une table de recherche comme un ensemble d'options qui ne définissent aucune relation. Exemple:
luCarMake
-----------
id Make
-- ---------
1 Audi
2 Chevy
3 Ford
La personne chargée de la base de données à mon travail suggère que je renomme plusieurs tables qui ne sont que des ID mappant une table à une autre en tant que tables de recherche. Exemple (Location_QuadMap ci-dessous):
Location
----------
LocationId
name
description
Location_QuadMap <-- suggesting i rename this to luLocationQuad
----------------
QuadMapId
LocationId
luQuadMap
---------
QuadMapId
QuadMapName
Est-il prudent de supposer qu'elle a mal lu le diagramme ou existe-t-il une autre définition que je ne connais pas?
Ce que vous avez là-bas s'appelle table de jonction . Il est également connu sous le nom de:
Mais je n'ai jamais vu le terme "table de consultation" utilisé à cet effet.
Choisissez vos batailles , mais je demanderais à la personne de clarifier la convention de dénomination en voyant qu'elle a suggéré d'utiliser le même convention pour les relations un-à-plusieurs et plusieurs-à-plusieurs. Il semble que toute relation de clé étrangère signifie qu'une table de "recherche" est impliquée.
Si c'est la convention de dénomination pour les autres bases de données, je ne pousserais pas ma chance.
Une table de recherche est normalement une table qui agit comme une "liste principale" pour quelque chose et vous l'utilisez pour rechercher une valeur de clé métier (comme "Make") en échange pour son identifiant (comme la colonne id) pour une utilisation dans d'autres colonne de clé étrangère de la table.
Fondamentalement, vous venez avec quelque chose à "rechercher" et l'échanger contre autre chose.
L'emplacement_quadmap d'autre part est une table de bridge qui, comme d'autres l'ont déjà dit, est utilisée lorsque vous avez une relation plusieurs-à-plusieurs entre deux entités. Si vous appelez cela une table de recherche, je dirais que n'importe quelle table pourrait être appelée une table de recherche. Ces tables ne contiennent que des identifiants pour d'autres tables, vous devez donc d'abord rechercher l'id sur une table, rechercher les identifiants qui correspondent dans la table de pont, puis rechercher les lignes correspondantes dans le 3e table? Semble pousser le terme un peu trop loin.
Mark Byers a la bonne définition pour cette table. Fondamentalement, une table d'intersection. Voir n'importe quel manuel de base de données.
Mais en réalité, j'ai travaillé avec de nombreux DBA/architectes et la plupart inventent leur propre style pour faire les choses et ne sont pas ouverts à entendre autre chose. Des choses comme les règles d'indentation, la casse pour les instructions SQL, les conventions de dénomination des tables (même les plus mauvaises), les stratégies d'archivage, etc. Vous n'avez fondamentalement pas le choix si elles contrôlent la base de données. Vous pouvez mentionner qu'il s'agit d'un tableau d'intersection, pointer vers la littérature appropriée, mais à la fin, si elle veut l'appeler MyStupidlyLongAndPointlessPrefixForTablesBecauseICan_Lookup_Location_Quadmap et insiste, il n'y a rien que vous puissiez faire.
Alors essayez de le lui faire remarquer, mais si elle ne l'accepte pas, ne le prenez pas trop au sérieux ...
Je viens de penser à autre chose. Les tables de recherche (notre définition) sont également appelées tables de code. Elle peut donc appeler des tables de recherche de tables d'intersection et des tables de code de tables de recherche. Dans ce cas, vous devrez peut-être apprendre à parler sa langue ...
Certaines personnes utilisent le terme table de consultation comme table qui se trouve au milieu d'une relation plusieurs à plusieurs.
Une utilisation de la table de recherche consiste à stocker autrement les valeurs enum
.
Disons que nous avons une énumération Status
.
Au lieu d'enregistrer "Non commencé", "En cours", "Terminé", "Renvoyé" ... dans chaque enregistrement de la base de données, nous enregistrons uniquement l'entier 1, 2, ... uniquement.
Côté programmation, l'ORM comme Entity Framework peut facilement convertir un entier sous-jacent en type Enum.
De cette façon, l'inconvénient est que la valeur entière n'est pas lisible du côté de la base de données. Pour résoudre ce problème, nous ajoutons un Lookup Table comme
Id Status
1 Not Started
2 In Progress
...
Pour que notre DBA puisse avoir un dictionnaire à "rechercher", montrant le texte d'état en se joignant à cette table de recherche.
La table de recherche est la table qui contient uniquement l'ID, le nom et la description d'un sujet/objet/chose. L'ID est la clé primaire et l'incrémentation automatique. Rien d'autre.