|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre du Club
![]() Inscription : décembre 2004 Messages : 82 ![]() |
bonjour,
souvent dans les tutoriels , oin parle d'une méthode d'indexation ou un concept qui s'applique sur les grandes tables. Ma question est :quand est ce que 'on peut dire qu'une table est de grande dimension? par exemple j'ai une table de 100 000 lignes , doit je installer un index? |
|
|
00
|
|
|
#2 |
|
Expert Confirmé
![]() ![]() Inscription : janvier 2005 Messages : 2 572 ![]() |
![]() Les index, si je ne me trompe pas, permettent d'accélerer la recherche sur les champs : c'est à dire que si tu as un champ que tu compares souvent ou qui est souvent en jointure, il vaut mieux l'indéxer. J'ai pas une grande expérience mais dans le dernier projet que j'ai eu à faire, j'avais des tables de 400000 enregistrements sur 11 champs et on m'a dit que c'était petit donc... PS : tu devrais modifier ton titre : ton problème apparement c'est les index et non la taille des tables
__________________
Pensez au tag ![]() Les règles du Forum Dev. Web : FAQ (X)HTML/CSS | Tutos (X)HTML | Tutos CSS PHP : FAQ PHP | Tutos PHP | Benchmark PHP 5 SQL : Cours SQL |
|
|
00
|
|
|
#3 |
|
Membre du Club
![]() Inscription : décembre 2004 Messages : 82 ![]() |
Merci pour ta réponse, en fait ce ke je voulais savoir c'est:
-est ce qu'il faut que je fasse un index sachant que il a un coût en espace ou bien travailler sans index car ma table de 100000 lignes à 10 champs est considérée comme petite. donc le probleme qui se pose est la taille de la table , mais bon si tu me dis que 400000 c'est petit alors ma table de 100000 c'est encore plus petit. |
|
|
00
|
|
|
#4 |
![]() ![]() Alain Ingénieur d'études décisionnel Inscription : mai 2002 Messages : 4 450 ![]() |
Tout doit être relativisé...
Dans quel environnement travailles-tu ? Sous quel SGBD ? 100 000 enregistrements pour Access, c'est une grosse table 1 000 000 000 pour ESSBase, c'est une table de taille moyenne... C'est comme dire qu'une 2CV consomme plus qu'une Ferrari parce qu'on fait moins de km avec un plein... |
|
|
00
|
|
|
#5 |
|
Membre du Club
![]() Inscription : décembre 2004 Messages : 82 ![]() |
je précise donc , c'est une base de donnée de géré par Mysql derniere version. elle est constituée de 400 000 lignes et 10 attributs.
un identifiant que je pense indexer. |
|
|
00
|
|
|
#6 |
![]() ![]() Alain Ingénieur d'études décisionnel Inscription : mai 2002 Messages : 4 450 ![]() |
Il est toujours utile d'indexer une table sur son identifiant pour optimiser les recherches (et les jointures) sur cet identifiant.
Si cet identifiant doit être unique, un index unique permet de faire vérifier cette unicité par le SGBD, ce qui sera moins lourd que par l'application. Si cet identifiant est utilisé comme clé étrangère par une autre table, il doit être unique et donc... |
|
|
00
|
|
|
#7 | |
![]() ![]() Inscription : janvier 2004 Messages : 15 861 ![]() |
Citation:
|
|
|
|
00
|
|
|
#8 | ||
![]() ![]() ![]() Frédéric BROUARDExpert SGBDR & SQL Inscription : mai 2002 Messages : 10 959 ![]() |
La taille d'une table s'évalue en Octets. Pas en nombre de ligne dou de colonnes (la notion d'attribut n'existe pas dans le domaine des SGBD).
De plus notion de grandeur doit être évaluée en fonction de la machine qui héberge la base... Une table de grande taille est donc une table qui occupera un espace mémoire (RAM) non négligeable. Quelques exemples : Code :
1) dans un SGBDR qui dispose de 256 Mo de RAM, ces tables sont elles grosses ? 2) dans un SGBDR qui dispose de 2 Go de RAM, ces tables sont elles grosses ? Solution : INT => 32 bits => 4 Octets * 1 000 000 => Taille approx de la table : 4 Mo. CHAR(2000) => 500 octets => 504 * 1 000 000 => 480 Mo 1) T1 petite, T2 grosse 2) T1 petite, T2 moyenne A +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/ Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp. Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * * |
||
|
00
|
Copyright © 2000-2012 - www.developpez.com