index postgresql sur la colonne chaîne
Disons, j'ai une table ResidentInfo, et dans cette table j'ai des contraintes uniques HomeAddress, qui sont de type VARCHAR. Pour une requête future, je vais ajouter un index sur cette colonne. La requête n'aura que l'opération =, et j'utiliserai le motif B-TREE car le motif de hachage n'est pas recommandé actuellement.
Question: Du point de vue de l'efficacité, en utilisant B-TREE, pensez-vous que je devrais ajouter une nouvelle colonne avec les nombres 1,2,3 ...., N correspondant à une homeaddress différente, et au lieu d'ajouter un index sur HomeAddress , Devrais-je ajouter un index sur la colonne numérique?
Je pose cette question parce que je ne sais pas comment fonctionne l'index.
Pour les vérifications d'égalité simples (=), un index B-Tree sur une colonne varchar ou text est simple et le meilleur choix. Cela aide certainement les performances beaucoup.
Bien sûr, un index B-Tree sur un simple integer fonctionne mieux. Pour commencer, la comparaison des valeurs simples de integer est un peu plus rapide. Mais plus important encore, les performances sont également fonction de la taille de l'indice. Une colonne plus grande signifie moins de lignes par page de données, signifie que plus de pages doivent être lues ...
Comme le HomeAddress n'est de toute façon pas unique, ce n'est pas une bonne clé primaire naturelle. Je suggère fortement d'utiliser à la place une clé primaire de substitution. Une colonne serial est le choix évident pour cela. Son seul but est d'avoir une clé primaire simple et rapide avec laquelle travailler.
Si vous avez d'autres tables référençant ladite table, cela devient encore plus efficace. Au lieu de dupliquer une longue chaîne pour la colonne de clé étrangère, vous n'avez besoin que des 4 octets pour une colonne entière. Et vous n'avez pas besoin de mettre en cascade autant de mises à jour, car une adresse est appelée à changer, tandis qu'un pk de substitution peut rester le même (mais pas nécessairement, bien sûr).
Votre table pourrait ressembler à ceci:
CREATE TABLE resident (
resident_id serial PRIMARY KEY
,address text NOT NULL
-- more columns
);
CREATE INDEX resident_adr_idx ON resident(address);
Il en résulte deux index B-Tree. Un index unique sur resident_id et un index simple sur address.
Plus d'informations sur les index dans le manuel .
Postgres offre beaucoup d'options - mais vous n'en avez plus besoin pour ce cas simple.
Dans Postgres, une contrainte unique est appliquée en maintenant un index unique sur le terrain, vous êtes donc déjà couvert.
Dans le cas où vous décidez que la contrainte unique sur l'adresse est mauvaise (ce qui, honnêtement, c'est: qu'est-ce qu'un conjoint créant un compte séparé? À propos des colocations? Etc.), vous pouvez en créer un comme ceci:
create index on ResidentInfo (HomeAddress);