Définir les clés et index sur une table
Résolu/Fermé
Blanc57
Messages postés
366
Date d'inscription
vendredi 6 avril 2007
Statut
Membre
Dernière intervention
27 janvier 2020
-
Modifié par Blanc57 le 3/02/2011 à 22:32
Blanc57 Messages postés 366 Date d'inscription vendredi 6 avril 2007 Statut Membre Dernière intervention 27 janvier 2020 - 7 févr. 2011 à 20:06
Blanc57 Messages postés 366 Date d'inscription vendredi 6 avril 2007 Statut Membre Dernière intervention 27 janvier 2020 - 7 févr. 2011 à 20:06
A voir également:
- Définir les clés et index sur une table
- Table ascii - Guide
- Table des matières word - Guide
- Index téléphonique - Guide
- Définir google comme page d'accueil - Guide
- Cles windows - Guide
4 réponses
Utilisateur anonyme
Modifié par baladur13 le 4/02/2011 à 17:43
Modifié par baladur13 le 4/02/2011 à 17:43
Bonjour,
Le choix des indexes dans une base dépend de deux choses, empêcher les doublons avec une clef primaire c'est à dire unique non nulle sur un ou plusieurs champs, des clefs de recherche, quand on questionne la base, quelles seront le requêtes les plus courantes et enfin sur quoi on trie l'affichage éventuellement
Ici je dirais que la recherche devrait sur faire sur date et time
On recherche pour un jour donné on on trie selon l'heure, mais c'est une vision des choses. Alors pourquoi par timestamp ?
C'est bien aussi mais il faut savoir que l'utilisation d'une fonction sur un index tue l'index dans une clause where, donc si tu utilise une fonction sur timestamp pour comparer avec le jour, exit l'index
Pour ton Pb de stats, il existe des outils libres qui font déjà des stats sur les serveurs Linux comme Webmin https://www.webmin.com/
Signature non conforme - Publicité supprimée Modération CCM
Le choix des indexes dans une base dépend de deux choses, empêcher les doublons avec une clef primaire c'est à dire unique non nulle sur un ou plusieurs champs, des clefs de recherche, quand on questionne la base, quelles seront le requêtes les plus courantes et enfin sur quoi on trie l'affichage éventuellement
Ici je dirais que la recherche devrait sur faire sur date et time
On recherche pour un jour donné on on trie selon l'heure, mais c'est une vision des choses. Alors pourquoi par timestamp ?
C'est bien aussi mais il faut savoir que l'utilisation d'une fonction sur un index tue l'index dans une clause where, donc si tu utilise une fonction sur timestamp pour comparer avec le jour, exit l'index
Pour ton Pb de stats, il existe des outils libres qui font déjà des stats sur les serveurs Linux comme Webmin https://www.webmin.com/
Signature non conforme - Publicité supprimée Modération CCM
Blanc57
Messages postés
366
Date d'inscription
vendredi 6 avril 2007
Statut
Membre
Dernière intervention
27 janvier 2020
72
4 févr. 2011 à 21:52
4 févr. 2011 à 21:52
Merci pour ta réponse internetwebservices
En fait mes recherches seront du genre :
select TIME,CPUTOTAL from INDIC_SRV1 where DATE='27.01.2011'
Je n'ai par contre pas bien sais ce que tu voulais dire par :
"il faut savoir que l'utilisation d'une fonction sur un index tue l'index dans une clause where, donc si tu utilise une fonction sur timestamp pour comparer avec le jour, exit l'index"
Voici mes créations de tables (sous DB2):
"create table VMSTAT_$SRV ( TS TIMESTAMP NOT NULL WITH DEFAULT, DATE DATE NOT NULL, TIME TIME NOT NULL, PROCWAIT SMALLINT, ACTVIRPAGES INT, PAGESIN SMALLINT, PAGESOUT SMALLINT, CPUUSER SMALLINT, CPUSYS SMALLINT, CPUWAIT SMALLINT, CPUTOTAL SMALLINT, FREEMEM INT );"
"create index IND_VMSTAT_$SRV on VMSTAT_$SRV (TS ASC);"
Je trouve mes requêtes tout de même assez longues, la génération des graphs depuis les fichiers CSV semblait plus rapide. Je devrais afficher plusieurs graphs par page et cela risque d'être trop long et inconfortable...
Je suis au courant qu'il existe déjà des produits mais ne pouvant installer de logiciels sur les serveurs, je ne peux faire qu'améliorer un système préexistant qui pour l'instant génère des fichiers HTML statiques, sans serveur web, par un script Perl et archivés au bout d'une semaine sous forme de zip.
Je peux donc réutiliser la partie "collecte des données sur les serveurs" qui remonte les données sous forme de CSV par TFTP sur une machine et à partir de là, exploiter ces données sur un serveur WEB avec BDD.
Merci encore.
En fait mes recherches seront du genre :
select TIME,CPUTOTAL from INDIC_SRV1 where DATE='27.01.2011'
Je n'ai par contre pas bien sais ce que tu voulais dire par :
"il faut savoir que l'utilisation d'une fonction sur un index tue l'index dans une clause where, donc si tu utilise une fonction sur timestamp pour comparer avec le jour, exit l'index"
Voici mes créations de tables (sous DB2):
"create table VMSTAT_$SRV ( TS TIMESTAMP NOT NULL WITH DEFAULT, DATE DATE NOT NULL, TIME TIME NOT NULL, PROCWAIT SMALLINT, ACTVIRPAGES INT, PAGESIN SMALLINT, PAGESOUT SMALLINT, CPUUSER SMALLINT, CPUSYS SMALLINT, CPUWAIT SMALLINT, CPUTOTAL SMALLINT, FREEMEM INT );"
"create index IND_VMSTAT_$SRV on VMSTAT_$SRV (TS ASC);"
Je trouve mes requêtes tout de même assez longues, la génération des graphs depuis les fichiers CSV semblait plus rapide. Je devrais afficher plusieurs graphs par page et cela risque d'être trop long et inconfortable...
Je suis au courant qu'il existe déjà des produits mais ne pouvant installer de logiciels sur les serveurs, je ne peux faire qu'améliorer un système préexistant qui pour l'instant génère des fichiers HTML statiques, sans serveur web, par un script Perl et archivés au bout d'une semaine sous forme de zip.
Je peux donc réutiliser la partie "collecte des données sur les serveurs" qui remonte les données sous forme de CSV par TFTP sur une machine et à partir de là, exploiter ces données sur un serveur WEB avec BDD.
Merci encore.
Utilisateur anonyme
7 févr. 2011 à 08:31
7 févr. 2011 à 08:31
Bonjour,
Pour ton select la clef sur la table doit être sur le champ date
Pour ce qui est des fonctions, imagine que tu recherches les données pour un mois donné, tu serais tenté de faire
select * from INDIC_SRV1 where to_char(DATE,'mmyyyy')='012011'
Ce genre de requête n'utilise pas l'index sur la date, car tu as utilisé la fonction to_char() qui transforme le champ, du coup toute la table est parcourue.
Dernier point je suis étonné que des requêtes soient plus lentes que la lecture d'un CSV, c'est un comble, il doit y avoir quelque chose de moisi dans tes requête ou ta structure, à moins que tes tables dépassent les 100 000 lignes, et encore avec DBII, ou alors ton serveur est une charrette.
Cordialement
Pour ton select la clef sur la table doit être sur le champ date
Pour ce qui est des fonctions, imagine que tu recherches les données pour un mois donné, tu serais tenté de faire
select * from INDIC_SRV1 where to_char(DATE,'mmyyyy')='012011'
Ce genre de requête n'utilise pas l'index sur la date, car tu as utilisé la fonction to_char() qui transforme le champ, du coup toute la table est parcourue.
Dernier point je suis étonné que des requêtes soient plus lentes que la lecture d'un CSV, c'est un comble, il doit y avoir quelque chose de moisi dans tes requête ou ta structure, à moins que tes tables dépassent les 100 000 lignes, et encore avec DBII, ou alors ton serveur est une charrette.
Cordialement
Blanc57
Messages postés
366
Date d'inscription
vendredi 6 avril 2007
Statut
Membre
Dernière intervention
27 janvier 2020
72
7 févr. 2011 à 20:06
7 févr. 2011 à 20:06
Bonjour,
Mes requêtes sont sur une journée, donc d'après ce qu'il me semble comprendre, il faut que je crée un index sur la date.
Quant à la lenteur :
- Mes tables font plus de 100.000 lignes (prêt de 1.500.000 lignes)
- C'est un vieux portable qui fait office de serveur juste pour développer mon projet
Forcément, dans ces conditions...
Merci encore pour ton aide.
Mes requêtes sont sur une journée, donc d'après ce qu'il me semble comprendre, il faut que je crée un index sur la date.
Quant à la lenteur :
- Mes tables font plus de 100.000 lignes (prêt de 1.500.000 lignes)
- C'est un vieux portable qui fait office de serveur juste pour développer mon projet
Forcément, dans ces conditions...
Merci encore pour ton aide.