Pourquoi une clé devrait-elle être explicite?

15

Je suis très nouveau dans le domaine des bases de données, donc cela peut sembler ignorant, mais je suis curieux de savoir pourquoi une clé doit être explicite dans une table. Est-ce principalement pour dire à l'utilisateur que la valeur de colonne donnée est (espérons-le) garantie d'être unique dans chaque ligne? L'unicité devrait toujours être là même si elle n'est pas mentionnée.

primary-key unique-constraint

— dsaxton
source

Voulez-vous dire que si vous avez une clé UNIQUE, pourquoi vous embêter à avoir une clé PRIMAIRE?

— Vérace

1

Pourquoi sont-ils déclarés? Cela semble très utile, mais est-il vraiment nécessaire d'avoir une base de données qui fonctionne?

— dsaxton

1

Ils ne sont pas nécessaires pour que votre base de données fonctionne, mais ils sont nécessaires pour que vos données "fonctionnent", c'est-à-dire qu'elles soient cohérentes, car c'est exactement ainsi que vous dites à votre serveur de base de données de conserver les informations cohérentes.

— Andriy M

Si la base de données sait qu'un champ donné est une clé, un effet secondaire est qu'elle peut vous aider à localiser la ligne contenant la clé beaucoup plus rapidement que si elle doit parcourir toutes les lignes des tables. Les index sont une partie très importante de la raison pour laquelle les bases de données sont utiles.

— Thorbjørn Ravn Andersen

32

Vous suggérez évidemment que les CONSTRAINTs dans une base de données devraient être appliqués par les applications qui accèdent à cette base de données?

Il y a plusieurs raisons pour lesquelles c'est une mauvaise (mauvaise, mauvaise ...) idée.

1) Si vous construisez un moteur de contrainte "roll-your-own" (c'est-à-dire dans votre code d'application), vous émulez simplement ce qu'Oracle / SQL Server / MySQL / PostgreSQL / <. Quiconque ...> a dépensé années d' écriture. Leur code CONSTRAINT a été testé au cours de ces années par des millions d'utilisateurs finaux.

2) Avec tout le respect que je vous dois ainsi qu'à votre équipe, vous n'allez pas faire les choses correctement, même dans quelques années - à partir d' ici , le code MySQL coûte à lui seul 40 millions de dollars. Et MySQL est le moins cher des 3 serveurs ci-dessus, et ils n'implémentent même pas CHECK CONSTRAINTs. De toute évidence, obtenir RI (Referential Integrity) complètement à droite est difficile.

J'avais l'habitude de fréquenter les forums Oracle et je ne peux pas vous dire le nombre de fois où un pauvre gestionnaire / programmeur s'est vu imposer un projet où le génie qui avait son travail avant a eu l'idée "brillante" de faire ce que vous suggérez .

Jonathan Lewis (il a écrit un livre de 550 pages sur les principes fondamentaux de l' optimiseur Oracle ) donne non. 2 de ses désastres de conception dans un autre livre (" Tales of the Oak Table " - la Oak Table est un groupe d'experts Oracle) est

Nous vérifierons l'intégrité des données au niveau de l'application au lieu de profiter des capacités de vérification des contraintes d'Oracle.

3) Même si, par miracle, vous pouvez correctement implémenter RI, vous devrez le réimplémenter complètement maintes et maintes fois pour chaque application qui touche cette base de données - et si vos données sont importantes, alors de nouvelles applications le feront. Choisir cela comme paradigme vous mènera, vous et vos collègues programmeurs (sans parler du personnel de soutien et des ventes), à une vie de lutte contre les incendies et de misère.

Vous pouvez en savoir plus sur la raison pour laquelle la mise en œuvre de CONTRAINTES de données au niveau de l'application n'est rien de moins que de la folie ici , ici et ici .

Pour répondre spécifiquement à votre question:

Pourquoi sont-ils déclarés? Cela semble très utile, mais est-il vraiment nécessaire d'avoir une base de données qui fonctionne

La raison pour laquelle KEYs (soit PRIMARY, FOREIGN, UNIQUEou tout simplement ordinaires INDEXes) sont déclarées est que, alors qu'il est pas strictement nécessaire à une base de données pour les avoir pour elle fonctionne, il est absolument nécessaire qu'ils soient déclarés pour qu'il fonctionne bien .

— Vérace
source

1

Merci pour votre réponse. J'aurai probablement besoin d'en savoir plus pour bien le comprendre. (Je n'appartiens pas à une équipe, j'apprends simplement les bases de données par curiosité.)

— dsaxton

2

Lisez quelques livres (Date, Garcia-Molina ...) et revenez vers nous si vous avez des questions spécifiques (les questions trop larges sont considérées hors sujet ici). ps Bienvenue sur le forum :-)

— Vérace

Bien que je ne suggérerais jamais de ne mettre aucune contrainte dans la base de données (vous devriez toujours avoir une clé primaire et des clés étrangères au minimum), vous pourriez éviter # 3 en faisant consommer toutes les applications à partir d'un service partagé (architecture orientée service ). (C'est probablement quelque chose que vous devriez considérer pour plusieurs consommateurs, de toute façon, comme faire chaque dernière vérification de l' intégrité dont vous avez besoin dans la base de données peut obtenir cauchemardesque, pense aussi que les déclencheurs faisant partout des contrôles à travers des tables et des lignes tout le temps..)

— jpmc26

10

Lorsque vous créez une clé dans une base de données, le moteur de SGBD applique une contrainte d'unicité sur les attributs de clé. Cela sert au moins trois objectifs connexes:

Intégrité des données: les données en double ne peuvent pas être entrées dans les attributs clés. Toutes les dépendances sur les clés sont donc garanties.
Identification: les utilisateurs peuvent s'appuyer sur des clés pour identifier et mettre à jour les données avec précision.
Optimisation: les informations (métadonnées) sur les attributs uniques sont disponibles pour l'optimiseur de requête SGBD. Ces informations permettent à l'optimiseur de simplifier l'exécution des requêtes de certaines manières afin que les requêtes s'exécutent plus rapidement.

— nvogel
source

8

J'ajouterai un aspect aux excellentes réponses existantes: la documentation. Il est souvent important de voir quels types de clés vous pouvez utiliser pour identifier une entité. Toute combinaison de colonnes uniques est une clé candidate.

La clé primaire tend à être un concept particulièrement utile dans la pratique.

Que vous appliquiez une clé ou non (vous devriez probablement le faire), la documentation est précieuse en soi.

— boot4life
source

1

Diagrammes de base de données! La première chose que je fais toujours lorsqu'on me demande de dire quelque chose de significatif sur un logiciel que je ne connais pas est de voir s'il utilise une base de données relationnelle, et si c'est le cas, essayez de créer un diagramme de base de données. Cela me donnera une excellente idée des informations avec lesquelles l'application fonctionne. Malheureusement, 90% des bases de données que j'ai vues ne déclarent pas de clés étrangères, donc les diagrammes ne sont que des ensembles de tables. La déduction de clés étrangères implicites au niveau de l'application nécessite des conjectures et des ajustements.

— reinierpost

1

@reinierpost Je suis entièrement d'accord. Les données sont l'objet le plus précieux à documenter et à conserver car elles persistent à tout jamais. Le code peut changer; il a tendance à être plus transitoire.

— boot4life

@reinierpost - Consulté pour une entreprise qui a fourni des logiciels pour l' ensemble de l'infrastructure ferroviaire d'un grand pays européen (grand - pensez à des milliards de widgets) et j'ai dit: "Hum, je vais juste lancer une requête pour vérifier les FOREIGN KEYdéfinitions pour obtenir un sentir pour le système ". Ma requête a renvoyé zip !!! Sûr que mon SQL devait être faux, j'en ai parlé à l'un des programmeurs seniors. Avec fierté (pas moins), il a annoncé (comme s'il présentait un fils nouveau-né) que le système n'avait pas de FK parce que "toutes les recherches sont sur PRIMARY KEYs" - (non pertinent). <Doh ...> à la Homer Simpson!

— Vérace

5

Une autre raison pour laquelle vous devriez utiliser des CONTRAINTES au lieu d'un code interne à l'application:

Que se passe-t-il si un développeur / dba utilise une instruction insert / update / delete pour modifier les données directement dans la base de données? Dans ce cas, toute votre intégrité référentielle basée sur une belle application sera inutile. Je sais, certains développeurs aiment la possibilité de modifier directement les données sans avoir à se soucier de RI car ils savent ce qu'ils font - au moins la plupart du temps (mais pas toujours)

PS: Bien sûr, vous pouvez créer des déclencheurs, mais ils sont généralement terriblement lents (par rapport aux CONTRAINTES).

— Thomas Franz
source