Je suis nouveau à Postgres et SQL en général. Je viens de Nosql. MongoDB plus spécifique. Dans Mongodb, chaque document avait une carte d'identité unique générée automatiquement par MongoDB.
Les rangées Postgres ont-elles automatiquement une pièce d'identité unique ou devez-vous les générer vous-même?
4 Réponses :
Vous devez définir un pour vous-même:
create table many_to_many ( one_id integer not null references table_one, other_id integer not null references other_table, primary key (one_id, other_id) );
Par conséquent, dans PostgreSQL, vous pouvez avoir des lignes qui ne peuvent pas être identifiées de manière unique si les données sont identiques?
@YulePale: Ils peuvent être identifiés par la clé primaire - et chaque table doit avoir une (c'est le principe de base des bases de données relationnelles)
Par conséquent, afin que je puisse identifier de manière unique des lignes dans PostgreSQL, j'ai besoin de dire explicitement PostgreSQL de créer un identifiant unique pour chaque rangée?
Lorsque vous dites "et chaque table doit avoir une", voulez-vous dire que la postgreSQL ou que le codeur devrait en faire un pour chaque table?
@YulePale: Non, vous n'avez pas besoin de générer un identifiant unique si votre modèle de données n'en a pas besoin. Si vous avez une clé primaire naturelle parfaitement naturelle pouvant être dérivée de vos données professionnelles, vous n'avez pas besoin d'une clé primaire générée. La définition de la clé principale est l'une des premières étapes de la conception de la base de données relationnelle.
Je pense que je comprends maintenant. PostgreSQL ne génère pas automatiquement une pièce d'identité unique comme MongoDB. Mais vous pouvez la définir si vous voulez? Ou définissez tout autre champ pour être la clé principale?
Chaque base de données a des identifiants uniques pour chaque ligne. Ces identifiants sont nécessaires, par exemple, pour les index sur d'autres colonnes afin de pouvoir être référencés.
postgres a réellement une variété d'identifiants internes. ici est une page de référence pour eux.
Cela dit, je pense que votre question est de savoir si Postgres fait automatiquement un tel identifiant disponible pour une utilisation par les utilisateurs. Permettez-moi de répondre à cela avec un «non», bien que vous puissiez accéder à certains des identifiants.
Cependant, il est très simple de créer un pour n'importe quelle table où vous en avez besoin. Voici deux méthodes courantes:
Par conséquent, afin que je puisse identifier de manière unique des lignes dans PostgreSQL, j'ai besoin de dire explicitement PostgreSQL de créer un identifiant unique pour chaque rangée?
" Chaque base de données a des identifiants uniques pour chaque ligne. " Êtes-vous sûr de la partie "TOUTES"? À ma connaissance, MySQL n'a pas cela. Si je ne me trompe pas, MySQL met toutes les colonnes d'une clé primaire dans la page d'index. (Je ne suis pas sûr de SQL Server, mais je pense que c'est du moins similaire avec des index en clusters)
@un cheval sans nom . . . Comment la base de données serait-elle capable de créer un index sur une table sans clé primaire? L'identifiant unique peut être une combinaison d'identifiant de table, d'identification de page et de compensation sur la page, mais ce serait toujours un identifiant unique. Les rangées ont pour être adressables pour prendre en charge certaines fonctionnalités SQL.
Vous n'avez pas à générer un ID artificiel pour votre table s'il y a une clé primaire naturelle. Vous pouvez les utiliser aussi comme des clés étrangères.
ID utilisateur, adresse e-mail, publication du gouvernement numéro d'identification personnel ou une résolution Nanoseconde Les horodatapes sont des exemples de telles clés.
Une adresse email est un très mauvais exemple d'une clé primaire naturelle. Typiquement, les gens en ont plus d'un, mais ce qui est encore plus important: ils changent.
Si vous écriez un logiciel de traitement de courrier, l'adresse électronique est un candidat parfait pour une clé primaire.
@a_horse_with_no_name Je n'ai pas dit que l'e-mail identifierait une personne - elle identifie une boîte aux lettres. Je veux avoir mon webmaster @ foo mails séparé de mon prénom @ foo emails. Et une plaque d'immatriculation de la voiture pourrait changer (si vous vendez votre voiture à Munch à une personne en Autriche), il n'est donc pas bon de suivre l'historique des services de vie du véhicule, mais je pourrais toujours utiliser le numéro de plaque d'immatriculation comme clé primaire dans un permis de stationnement ou une application de location de voiture.
@YulePale, en passant dans un environnement avec des règles différentes, c'est toujours une sorte de ... fatigant. Ils prétendent que c'est bon pour votre cerveau, mais apprendre un nouveau paradigme n'est pas une chose d'une journée.
Je réponds parce que vous avez demandé des variations de "dans PostgreSQL, vous pouvez avoir des lignes non identifiées si les données est le même?" Question équitable, mais il est important de penser à cela comme une caractéristique type de tout point dans une base de données relationnelle consiste à pas avoir des rangées identiques. Imaginez que vous avez deux documents qui sont exactement les mêmes et que vous les stockez dans deux rangées. De quelle manière sont-ils différents? Il n'y a rien à propos d'eux qui est différent. Alors pourquoi avez-vous deux rangées? S'il y a des informations supplémentaires pour les distinguer, alors cela est probablement quelque chose à avoir dans la rangée aussi. Peut-être qu'ils sont venus de différentes sources, alors vous stockez un chemin avec chaque document. déterminer ce que dans les données identifie de manière unique chaque ligne est le point de départ de la conception de la table. Ce pourrait être un champ "naturel", mais c'est assez rare. Ce pourrait être une combinaison de champs. Il est courant de générer un ID (un numéro séquentiel ou un UUID) comme commodité . Mais boulonner un numéro unique sur des lignes identiques est un mauvais plan. Cet identifiant à l'avant rend les rangées uniques, mais les données ne sont pas uniques. Prétendre qu'il n'y a vraiment qu'un seul Dan Perkins à cette adresse. Vous avez maintenant de mauvaises données. Ce genre de chose se termine toujours en larmes. Le paradigme Mongo et la conception de la base de données relationnelle sont différents. Vous allez vous faire une faveur pour essayer de vous familiariser avec une conception relationnelle. Ensuite, vous pouvez vraiment exploiter le pouvoir d'un outil tel que Postgres. Clés étrangères, Je ne sais pas où vous les trouverez, mais vérifiez Dans les personnes qui ont déménagé de Mongo à un SGBDM peuvent vous être utiles pendant la transition. Je ne connais pas Mongo, mais il y a beaucoup de gens qui connaissent à la fois Mongo et Postgres. En fait, un important contributeur postgres est également derrière un outil que vous pourriez trouver d'intérêt? Je viens de le regarder, et il semble que Mongodb génère un nombre semi-aléatoire de base-12 pour les ID de la rangée: rejoindre et vérifier Les contraintes vont probablement être vos amis.
Merci pour l'explication. J'étais surtout confondu sur la partie génération d'identification. Maintenant que je le comprends, je trouve SQL, la majeure partie de la pièce, facile à apprendre.