J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
François 37
http://sqlpro.developpez.com/
De par l'expérience des dev en SQL 2000 Il apparait que : 1. il faut une primary key integer pour les tables pour gérer les insertions 2. il est inutile d'indexer à moins de 1000 enregistrements 3. Il est inutile d'indexer sur des champs ayant une faible sélectivité (True False) 4. faire attention comment on pose les requêtes
"Laurent" a écrit dans le message de news:
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
http://sqlpro.developpez.com/
De par l'expérience des dev en SQL 2000
Il apparait que :
1. il faut une primary key integer pour les tables pour gérer les insertions
2. il est inutile d'indexer à moins de 1000 enregistrements
3. Il est inutile d'indexer sur des champs ayant une faible sélectivité
(True False)
4. faire attention comment on pose les requêtes
"Laurent" <Laurent@discussions.microsoft.com> a écrit dans le message de
news:4A34BF88-47F2-4BDD-BD27-6732BA971492@microsoft.com...
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.
De par l'expérience des dev en SQL 2000 Il apparait que : 1. il faut une primary key integer pour les tables pour gérer les insertions 2. il est inutile d'indexer à moins de 1000 enregistrements 3. Il est inutile d'indexer sur des champs ayant une faible sélectivité (True False) 4. faire attention comment on pose les requêtes
"Laurent" a écrit dans le message de news:
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
Patrice
Essaye Google ou http://sql.developpez.com/, le site de Fred...
Le problème revient à "le jeu en vaut il la chandelle" : 1) - ??? 2) Le volume de l'index sera grand donc moins efficace à parcourir qu'un index "compact" 3) Si l'index permet de choisir 1 ligne parmi 10000, il sera utile, si il permet de choisir 5000 ligne parmi 10000, cela permet de n'éliminer q'une ligne sur 2
"En consultation" ou en "mise à jour" ? Apès le problème est que les index doivent être mis à jour...
Je pense que le plus simple est toujours de tester ton cas concret : 1) Est-ce que tu sélectionne sur cette colonne ? 2) Si oui est-ce que c'est long et/ou fréquent ? 3) Si tu ajoutes un index qu'est ce que tu gagnes ?
Par exemple un cas que tu ne cites pas concerne les tables de faible nombre d'enregistrements. A priori SQL Server peut très bien décider de ne pas utiliser l'index dans ce cas même si présent (en considérant que la lecture totale d'une table de faible taille sera aussi rapide que de lire l'index puis d'aller chercher la page concernée).
Patrice --
"Laurent" a écrit dans le message de news:
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
Essaye Google ou http://sql.developpez.com/, le site de Fred...
Le problème revient à "le jeu en vaut il la chandelle" :
1) - ???
2) Le volume de l'index sera grand donc moins efficace à parcourir qu'un
index "compact"
3) Si l'index permet de choisir 1 ligne parmi 10000, il sera utile, si il
permet de choisir 5000 ligne parmi 10000, cela permet de n'éliminer q'une
ligne sur 2
"En consultation" ou en "mise à jour" ? Apès le problème est que les index
doivent être mis à jour...
Je pense que le plus simple est toujours de tester ton cas concret :
1) Est-ce que tu sélectionne sur cette colonne ?
2) Si oui est-ce que c'est long et/ou fréquent ?
3) Si tu ajoutes un index qu'est ce que tu gagnes ?
Par exemple un cas que tu ne cites pas concerne les tables de faible nombre
d'enregistrements. A priori SQL Server peut très bien décider de ne pas
utiliser l'index dans ce cas même si présent (en considérant que la lecture
totale d'une table de faible taille sera aussi rapide que de lire l'index
puis d'aller chercher la page concernée).
Patrice
--
"Laurent" <Laurent@discussions.microsoft.com> a écrit dans le message de
news:4A34BF88-47F2-4BDD-BD27-6732BA971492@microsoft.com...
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.
Essaye Google ou http://sql.developpez.com/, le site de Fred...
Le problème revient à "le jeu en vaut il la chandelle" : 1) - ??? 2) Le volume de l'index sera grand donc moins efficace à parcourir qu'un index "compact" 3) Si l'index permet de choisir 1 ligne parmi 10000, il sera utile, si il permet de choisir 5000 ligne parmi 10000, cela permet de n'éliminer q'une ligne sur 2
"En consultation" ou en "mise à jour" ? Apès le problème est que les index doivent être mis à jour...
Je pense que le plus simple est toujours de tester ton cas concret : 1) Est-ce que tu sélectionne sur cette colonne ? 2) Si oui est-ce que c'est long et/ou fréquent ? 3) Si tu ajoutes un index qu'est ce que tu gagnes ?
Par exemple un cas que tu ne cites pas concerne les tables de faible nombre d'enregistrements. A priori SQL Server peut très bien décider de ne pas utiliser l'index dans ce cas même si présent (en considérant que la lecture totale d'une table de faible taille sera aussi rapide que de lire l'index puis d'aller chercher la page concernée).
Patrice --
"Laurent" a écrit dans le message de news:
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
Fabian SIRACH [MS]
Bonjour,
Si le design de votre base est terminé et que vous avez des données à disposition, vous pouvez utiliser "l'Index Tuning Wizard" de SQL Server qui vous donnera une première idée des optimisations possibles sur la table et vous proposer l'ajout ou non d'index sur les colonnes pertinentes aux requêtes utilisées.
Cordialement
Fabian
"Patrice" wrote in message news:%
Essaye Google ou http://sql.developpez.com/, le site de Fred...
Le problème revient à "le jeu en vaut il la chandelle" : 1) - ??? 2) Le volume de l'index sera grand donc moins efficace à parcourir qu'un index "compact" 3) Si l'index permet de choisir 1 ligne parmi 10000, il sera utile, si il permet de choisir 5000 ligne parmi 10000, cela permet de n'éliminer q'une ligne sur 2
"En consultation" ou en "mise à jour" ? Apès le problème est que les index doivent être mis à jour...
Je pense que le plus simple est toujours de tester ton cas concret : 1) Est-ce que tu sélectionne sur cette colonne ? 2) Si oui est-ce que c'est long et/ou fréquent ? 3) Si tu ajoutes un index qu'est ce que tu gagnes ?
Par exemple un cas que tu ne cites pas concerne les tables de faible nombre d'enregistrements. A priori SQL Server peut très bien décider de ne pas utiliser l'index dans ce cas même si présent (en considérant que la lecture totale d'une table de faible taille sera aussi rapide que de lire l'index puis d'aller chercher la page concernée).
Patrice --
"Laurent" a écrit dans le message de news:
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
Bonjour,
Si le design de votre base est terminé et que vous avez des données à
disposition, vous pouvez utiliser "l'Index Tuning Wizard" de SQL Server qui
vous donnera une première idée des optimisations possibles sur la table et
vous proposer l'ajout ou non d'index sur les colonnes pertinentes aux
requêtes utilisées.
Cordialement
Fabian
"Patrice" <nobody@nowhere.com> wrote in message
news:%23ZH6y2oGFHA.2900@TK2MSFTNGP10.phx.gbl...
Essaye Google ou http://sql.developpez.com/, le site de Fred...
Le problème revient à "le jeu en vaut il la chandelle" :
1) - ???
2) Le volume de l'index sera grand donc moins efficace à parcourir qu'un
index "compact"
3) Si l'index permet de choisir 1 ligne parmi 10000, il sera utile, si il
permet de choisir 5000 ligne parmi 10000, cela permet de n'éliminer q'une
ligne sur 2
"En consultation" ou en "mise à jour" ? Apès le problème est que les index
doivent être mis à jour...
Je pense que le plus simple est toujours de tester ton cas concret :
1) Est-ce que tu sélectionne sur cette colonne ?
2) Si oui est-ce que c'est long et/ou fréquent ?
3) Si tu ajoutes un index qu'est ce que tu gagnes ?
Par exemple un cas que tu ne cites pas concerne les tables de faible
nombre
d'enregistrements. A priori SQL Server peut très bien décider de ne pas
utiliser l'index dans ce cas même si présent (en considérant que la
lecture
totale d'une table de faible taille sera aussi rapide que de lire l'index
puis d'aller chercher la page concernée).
Patrice
--
"Laurent" <Laurent@discussions.microsoft.com> a écrit dans le message de
news:4A34BF88-47F2-4BDD-BD27-6732BA971492@microsoft.com...
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.
Si le design de votre base est terminé et que vous avez des données à disposition, vous pouvez utiliser "l'Index Tuning Wizard" de SQL Server qui vous donnera une première idée des optimisations possibles sur la table et vous proposer l'ajout ou non d'index sur les colonnes pertinentes aux requêtes utilisées.
Cordialement
Fabian
"Patrice" wrote in message news:%
Essaye Google ou http://sql.developpez.com/, le site de Fred...
Le problème revient à "le jeu en vaut il la chandelle" : 1) - ??? 2) Le volume de l'index sera grand donc moins efficace à parcourir qu'un index "compact" 3) Si l'index permet de choisir 1 ligne parmi 10000, il sera utile, si il permet de choisir 5000 ligne parmi 10000, cela permet de n'éliminer q'une ligne sur 2
"En consultation" ou en "mise à jour" ? Apès le problème est que les index doivent être mis à jour...
Je pense que le plus simple est toujours de tester ton cas concret : 1) Est-ce que tu sélectionne sur cette colonne ? 2) Si oui est-ce que c'est long et/ou fréquent ? 3) Si tu ajoutes un index qu'est ce que tu gagnes ?
Par exemple un cas que tu ne cites pas concerne les tables de faible nombre d'enregistrements. A priori SQL Server peut très bien décider de ne pas utiliser l'index dans ce cas même si présent (en considérant que la lecture totale d'une table de faible taille sera aussi rapide que de lire l'index puis d'aller chercher la page concernée).
Patrice --
"Laurent" a écrit dans le message de news:
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas
mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
Med Bouchenafa
> En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY. C'est à vous de les mettre en place si le nombre de ligne en vaut la chandelle
Il est impossible de créer une FOREIGN KEY référençant une colonne qui ne possède pas un INDEX UNIQUE de manière directe ou indirercte Seules les colonnes en PRIMARY KEY, UNIQUE ou possèdant un INDEX UNIQUE peuvent être référencées
-- Bien cordialement Med Bouchenafa
"brouardf" a écrit dans le message de news:
Laurent a écrit :
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne pas mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible selectivité. Est-il possible d'avoir une explication ou un lien expliquant le pourquoi du comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
en complément si email est muni d'une contrainte d'unicité, SQL Server à créé un index sans vous le dire. Dans les cas de PRIMARY KEY et UNIQUE CONSTRAINT SQL Server (comme Oracle ou IBM DB2) créé un index. En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY. C'est à vous de les mettre en place si le nombre de ligne en vaut la chandelle.
A +
> En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY.
C'est à vous de les mettre en place si le nombre de ligne en vaut la
chandelle
Il est impossible de créer une FOREIGN KEY référençant une colonne qui ne
possède pas un INDEX UNIQUE de manière directe ou indirercte
Seules les colonnes en PRIMARY KEY, UNIQUE ou possèdant un INDEX UNIQUE
peuvent être référencées
--
Bien cordialement
Med Bouchenafa
"brouardf" <brouardf@club-internet.fr> a écrit dans le message de news:
uolIoEpGFHA.3628@TK2MSFTNGP15.phx.gbl...
Laurent a écrit :
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne
pas mettre d'index car les temps de réponse (en consultation) sont
dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible
selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi
du comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.
en complément si email est muni d'une contrainte d'unicité, SQL Server à
créé un index sans vous le dire. Dans les cas de PRIMARY KEY et UNIQUE
CONSTRAINT SQL Server (comme Oracle ou IBM DB2) créé un index.
En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY.
C'est à vous de les mettre en place si le nombre de ligne en vaut la
chandelle.
> En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY. C'est à vous de les mettre en place si le nombre de ligne en vaut la chandelle
Il est impossible de créer une FOREIGN KEY référençant une colonne qui ne possède pas un INDEX UNIQUE de manière directe ou indirercte Seules les colonnes en PRIMARY KEY, UNIQUE ou possèdant un INDEX UNIQUE peuvent être référencées
-- Bien cordialement Med Bouchenafa
"brouardf" a écrit dans le message de news:
Laurent a écrit :
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne pas mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible selectivité. Est-il possible d'avoir une explication ou un lien expliquant le pourquoi du comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
en complément si email est muni d'une contrainte d'unicité, SQL Server à créé un index sans vous le dire. Dans les cas de PRIMARY KEY et UNIQUE CONSTRAINT SQL Server (comme Oracle ou IBM DB2) créé un index. En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY. C'est à vous de les mettre en place si le nombre de ligne en vaut la chandelle.
A +
brouardf
Laurent a écrit :
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne pas mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible selectivité. Est-il possible d'avoir une explication ou un lien expliquant le pourquoi du comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
en complément si email est muni d'une contrainte d'unicité, SQL Server à créé un index sans vous le dire. Dans les cas de PRIMARY KEY et UNIQUE CONSTRAINT SQL Server (comme Oracle ou IBM DB2) créé un index. En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY. C'est à vous de les mettre en place si le nombre de ligne en vaut la chandelle.
A +
Laurent a écrit :
Bonjour,
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne pas
mettre d'index car les temps de réponse (en consultation) sont dégradés.
Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null
Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine
taille
Exemple 3: ne pas mettre d'index sur des colonne ayant une faible selectivité.
Est-il possible d'avoir une explication ou un lien expliquant le pourquoi du
comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique
mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur
cette colonne ?
Merci d'avance pour vos réponses.
en complément si email est muni d'une contrainte d'unicité, SQL Server à
créé un index sans vous le dire. Dans les cas de PRIMARY KEY et UNIQUE
CONSTRAINT SQL Server (comme Oracle ou IBM DB2) créé un index.
En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY.
C'est à vous de les mettre en place si le nombre de ligne en vaut la
chandelle.
J'ai lu dans divers ouvrage qu'il y avait des cas ou il fallait mieux ne pas mettre d'index car les temps de réponse (en consultation) sont dégradés. Exemple 1: ne pas mettre d'index sur les colonnes pouvant être null Exemple 2: ne pas mettre d'index sur les colonnes dépassant une certaine taille Exemple 3: ne pas mettre d'index sur des colonne ayant une faible selectivité. Est-il possible d'avoir une explication ou un lien expliquant le pourquoi du comment.
Enfin dans une table, j'ai un champ "email" de taille 50, qui est unique mais qui n'est pas la clé primaire. Est ce que je dois créer un index sur cette colonne ? Merci d'avance pour vos réponses.
en complément si email est muni d'une contrainte d'unicité, SQL Server à créé un index sans vous le dire. Dans les cas de PRIMARY KEY et UNIQUE CONSTRAINT SQL Server (comme Oracle ou IBM DB2) créé un index. En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY. C'est à vous de les mettre en place si le nombre de ligne en vaut la chandelle.
A +
brouardf
Med Bouchenafa a écrit :
En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY. C'est à vous de les mettre en place si le nombre de ligne en vaut la chandelle
Il est impossible de créer une FOREIGN KEY référençant une colonne qui ne possède pas un INDEX UNIQUE de manière directe ou indirercte Seules les colonnes en PRIMARY KEY, UNIQUE ou possèdant un INDEX UNIQUE peuvent être référencées
on est bien d'accord...
Une FOREIGN KEY fait référence à une clef ou une contrainte d'unicité => index posé sur les clef et les contraintes d'unicité. En revanche les colonnes composant la clef étrangère ne sont pas indexées.
A +
Med Bouchenafa a écrit :
En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY.
C'est à vous de les mettre en place si le nombre de ligne en vaut la
chandelle
Il est impossible de créer une FOREIGN KEY référençant une colonne qui ne
possède pas un INDEX UNIQUE de manière directe ou indirercte
Seules les colonnes en PRIMARY KEY, UNIQUE ou possèdant un INDEX UNIQUE
peuvent être référencées
on est bien d'accord...
Une FOREIGN KEY fait référence à une clef ou une contrainte d'unicité =>
index posé sur les clef et les contraintes d'unicité. En revanche les
colonnes composant la clef étrangère ne sont pas indexées.
En revanche aucun index n'est créé sur les colonnes de type FOREIGN KEY. C'est à vous de les mettre en place si le nombre de ligne en vaut la chandelle
Il est impossible de créer une FOREIGN KEY référençant une colonne qui ne possède pas un INDEX UNIQUE de manière directe ou indirercte Seules les colonnes en PRIMARY KEY, UNIQUE ou possèdant un INDEX UNIQUE peuvent être référencées
on est bien d'accord...
Une FOREIGN KEY fait référence à une clef ou une contrainte d'unicité => index posé sur les clef et les contraintes d'unicité. En revanche les colonnes composant la clef étrangère ne sont pas indexées.