Si je n'ai pas besoin d'une clé primaire, je ne l'ajoute pas à la base de données?
12 Réponses :
Si vous n'avez pas besoin d'une clé primaire, n'utilisez-en aucun. J'ai généralement le besoin de clés primaires, alors je les utilise habituellement. Si vous avez des tables connexes, vous voulez probablement des clés primaires et étrangères.
Une clé primaire aidera toujours avec la performance de la requête. Donc, si vous avez besoin d'interroger à l'aide de la "touche" à une "touche étrangère" ou utilisée comme recherche, puis oui, crée une clé étrangère.
Je n'ai pas le fait, que les clés primaires aident à la performance? Si vous n'en avez pas besoin, vous ne recherchez pas les enregistrements en utilisant un. Donc, il n'y a pas d'avantage.
Quelle sera la table pour ensuite? Nous avons surtout besoin de la table pour stocker des informations et vous rechercherez des valeurs.
Luke101 devrait poster son cas d'utilisation et nous verrons, s'il en a besoin.
Oui, mais seulement dans le même sens que ce sera bien de ne pas utiliser une ceinture de sécurité si vous ne prévoyez pas d'être dans un accident. C'est-à-dire que c'est un petit prix de payer un grand avantage lorsque vous en avez besoin, et même si vous pensez que vous n'en avez pas besoin de cotes, êtes-vous à l'avenir. La différence est que vous êtes beaucoup plus susceptibles d'avoir besoin d'une clé primaire que d'obtenir un accident de voiture.
Vous devez également savoir que certains systèmes de base de données créent une clé primaire pour vous si vous ne le faites pas, donc vous ne sauvegardez pas beaucoup de ce qui se passe dans le moteur.
Je ne suis pas d'accord. Je refuse de porter des ceintures de sécurité car ils m'empêchent un accès complet à ma bière. Mais je ne créerai jamais une table sans pk.
@Rev Gonzo, ce dont vous avez besoin est un porte-bière plus placé stratégiquement. Allez, c'est 2010.
Vous avez besoin d'une clé primaire. Vous ne le savez pas encore.
Une fois, j'ai pensé que je n'avais pas besoin d'une clé primaire non plus ... Maintenant, je sais mieux.
+1 parce que cela reflète les plus précisément la réalité. Je peux voir des cas où l'on pourrait ne pas avoir besoin d'un autre et de loin entre.
Sauf lorsque vous n'avez pas besoin d'une clé primaire et que vous le savez maintenant. C'est un cas inhabituel cependant. Mieux vaut jouer en toute sécurité et erreur en faveur d'un pk.
Je suis d'accord avec votre, mais si quelqu'un n'accepte pas avec vous et moi, cet argument ne les convaincra jamais.
Une clé primaire identifie de manière unique une ligne de votre table.
Le fait qu'il soit indexé et / ou en cluster est un problème de mise en œuvre physique et sans rapport avec la conception logique.
Vous avez besoin d'un pour la table pour avoir un sens.
Je ne sais pas. J'ai utilisé quelques tables où il n'y a qu'une seule rangée et une seule colonne. Ne sera toujours qu'une seule rangée et une seule colonne. Il n'y a pas de relations clés étrangères.
Pourquoi devrais-je mettre une clé primaire à ce sujet?
Vous devez stocker une seule information? Quelque chose comme un système large préférence? Tout le monde a besoin de ce morceau de données, mais vous ne voulez pas créer une toute nouvelle chose pour obtenir à cette pièce de données.
Ah. Mais vous voulez une clé primaire sur cette table. Et une contrainte de contrôle qui limite cette clé primaire à une seule valeur. Parce que vous revenez autrement, vous revenez dans 6 mois et trouvez que quelqu'un d'autre a ajouté une autre ligne pour vous et laquelle votre application ramasse est arbitraire ...
Une clé primaire est principalement définie officiellement pour aider l'intégrité référenciale, cependant, si la table est très petite, ou il est peu probable qu'il contienne des données uniques, il s'agit d'une surcharge non nécessaire. La définition des index sur la table peut normalement être utilisée pour impliquer une clé primaire sans déclarer formellement une. Toutefois, vous devriez considérer que la définition de la clé principale peut être utile pour les développeurs et la génération de schéma ou les outils SQL Dev, comme l'aide des métadonnées contribue à la compréhension et que certains outils s'appuient à ce sujet pour définir correctement les relations principales / étrangères dans le modèle. < / p>
Eh bien ...
Chaque table dans un DB relationnel a besoin d'une clé primaire. Comme indiqué précédemment, une clé primaire est des données qui identifient un enregistrement unique ...
Vous pourriez vous échapper sans avoir un champ "ID", si vous avez une table N-M qui rejoint 2 tables différentes, mais vous pouvez identifier uniquement l'enregistrement des valeurs des deux colonnes que vous adhérez. (Clé primaire composite)
Avoir une table sans une clé primaire est contre la première forme normale et n'a rien à voir dans une DB relationnelle
Non, à moins que vous ne puissiez trouver un exemple de ", cette base de données fonctionnerait tellement mieux si table_x n'avait pas une clé primaire".
Vous pouvez faire une argument pour ne jamais utiliser une clé primaire, si la performance, l'intégrité des données et la normalisation ne sont pas nécessaires. Les capacités de sécurité et de sauvegarde / restauration peuvent ne pas être nécessaires, mais éventuellement, vous mettez votre pantalon de gros garçons et rejoignez le monde réel de la mise en œuvre de la base de données.
Oui, une table doit toujours avoir une clé primaire ... à moins que vous n'ayez pas besoin d'identifier de manière unique les enregistrements dedans. (J'aime faire des déclarations absolues et les contredire immédiatement)
Quand n'auriez-vous pas besoin d'identifier de manière unique les enregistrements dans une table? Presque jamais. Je l'ai déjà fait auparavant pour des choses comme des tables de journal d'audit. Les données qui ne seront pas mises à jour ou supprimées et ne seront pas contraintes de quelque manière que ce soit. Lancement essentiellement structuré.
Vous devez toujours avoir une clé primaire, même si c'est juste sur ID. Peut-être que Nosql est ce que vous êtes après (juste demander)?
Cela dépend beaucoup de ce que vous pouvez être sûr que vous n'en avez pas besoin. Si vous avez le moins de doute, ajoutez-en un - vous vous remercierez plus tard. Un indicateur étant si les données que vous stockez pourraient être liées à d'autres données de votre DB à un moment donné.
Un cas d'utilisation, je peux penser à une table de journalisation de la journalisation, dans laquelle vous viderez simplement une entrée après l'autre (pour les traiter correctement plus tard). Vous n'aurez probablement pas besoin d'une clé primaire là-bas, si vous stockez suffisamment de données pour filtrer les messages pertinents (comme une date). Bien sûr, il est douteux d'utiliser un SGBDM pour cela.
Il n'y a guère aucun cas où vous n'avez pas besoin d'une clé primaire. Fondamentalement, si une table n'a pas de clé primaire, ce n'est pas une table - ce n'est qu'un tas de données.
Cela peut ne pas être pertinent pour votre question, mais j'ai besoin de demander: Pourquoi ne sentez-vous pas que vous en avez besoin?
Pouvez-vous nous donner plus d'informations sur la situation que vous utilisez? Les clés primaires ne sont pas toujours nécessaires, mais si nous savions ce que vous essayiez de faire, nous pourrions peut-être vous donner de meilleurs conseils.
Pouvez-vous nous donner une explication sur la raison pour laquelle vous pensez avoir peut-être besoin d'un pkkey? Je ne peux pas vraiment penser à une raison de l'omettre jamais. Même un modèle de données d'un tableau a besoin d'un pkkey à une ligne unique d'une ligne.
Les gens continuent à supposer que vous devez identifier de manière unique une rangée ... ce que je trouve intéressant. Imaginez une sorte de log / compteur - tout ce que j'ai besoin de savoir, c'est que quelque chose s'est passé et quand, à la minute la plus proche. J'ai donc un identifiant d'événement et un timbre horaire et c'est tout ce dont j'ai besoin parce que tout ce que je veux faire est de stocker et de compter les cas d'événement. Contrié je vais admettre mais pas complètement là-bas.
J'ai des tables de journalisation comme Murph suggère. Lorsque vous avez des événements pouvant être identiques, mais se produisent en même temps (surtout si vous utilisez SmallDateTime), qu'est-ce que vous utilisez pour la clé primaire et pourquoi? Les PKS ne sont pas nécessaires pour la performance (les index en clusters ne doivent avoir rien à voir avec le PK) et si vous n'avez pas non plus besoin de regarder quelque chose ... dans des cas comme celui-ci, j'utilise des vues indexées pour fournir des statistiques agrégées mais Je ne vois aucune raison de définir un pk. Je suis d'accord cependant que dans la plupart des cas, vous voulez une clé primaire, et dans la plupart des cas où vous pensez que vous n'en avez pas besoin, vous le faites vraiment.