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
Denis Beauregard
Le Mon, 2 Jun 2008 14:46:55 +0200, "Xavier" écrivait dans fr.comp.applications.sgbd:
Bonjour,
Je vais créer une table avec un champ varchar(10).
Au bout de combien d'enregistrement ça commence à poser des problemes pour les requetes "where mon_varchar = "xx123x" ".
J'ai juste 2 - 3 champs dans la table .
60 000 enregistrements ça marchera bien, 200 000 ?
C'est encore très loin de la limite en soi. Ce qui ne signifie pas que ce sera rapide.
Le truc à savoir : le serveur peut copier la base entièrement en mémoire si vous êtes seul à utiliser le serveur, ce qui donnera l'impression en local que c'est très rapide. Mais si le serveur Internet utilisé a beaucoup d'utilisateurs, avec la même base, il pourrait devenir lent.
De plus, la longueur des champs a un effet (si chaque champ a 10 caractères par rapport à 1000 par exemple).
Pour référence, j'ai une base qui a 600 000 enregistrements et occupe 100 Mo. Pour la recherche, j'ai extrait certaines colonnes pour obtenir 50 Mo, ce qui réduit le temps de réponse à une durée acceptable. Je pourrais encore réduire ce temps avec des versions indexées en fonction des recherches les plus fréquentes.
Denis
Le Mon, 2 Jun 2008 14:46:55 +0200, "Xavier" <xav1980@nospamsvp.com>
écrivait dans fr.comp.applications.sgbd:
Bonjour,
Je vais créer une table avec un champ varchar(10).
Au bout de combien d'enregistrement ça commence à poser des problemes pour
les requetes "where mon_varchar = "xx123x" ".
J'ai juste 2 - 3 champs dans la table .
60 000 enregistrements ça marchera bien, 200 000 ?
C'est encore très loin de la limite en soi. Ce qui ne signifie pas
que ce sera rapide.
Le truc à savoir : le serveur peut copier la base entièrement en
mémoire si vous êtes seul à utiliser le serveur, ce qui donnera
l'impression en local que c'est très rapide. Mais si le serveur
Internet utilisé a beaucoup d'utilisateurs, avec la même base,
il pourrait devenir lent.
De plus, la longueur des champs a un effet (si chaque champ a
10 caractères par rapport à 1000 par exemple).
Pour référence, j'ai une base qui a 600 000 enregistrements et
occupe 100 Mo. Pour la recherche, j'ai extrait certaines colonnes
pour obtenir 50 Mo, ce qui réduit le temps de réponse à une durée
acceptable. Je pourrais encore réduire ce temps avec des versions
indexées en fonction des recherches les plus fréquentes.
Le Mon, 2 Jun 2008 14:46:55 +0200, "Xavier" écrivait dans fr.comp.applications.sgbd:
Bonjour,
Je vais créer une table avec un champ varchar(10).
Au bout de combien d'enregistrement ça commence à poser des problemes pour les requetes "where mon_varchar = "xx123x" ".
J'ai juste 2 - 3 champs dans la table .
60 000 enregistrements ça marchera bien, 200 000 ?
C'est encore très loin de la limite en soi. Ce qui ne signifie pas que ce sera rapide.
Le truc à savoir : le serveur peut copier la base entièrement en mémoire si vous êtes seul à utiliser le serveur, ce qui donnera l'impression en local que c'est très rapide. Mais si le serveur Internet utilisé a beaucoup d'utilisateurs, avec la même base, il pourrait devenir lent.
De plus, la longueur des champs a un effet (si chaque champ a 10 caractères par rapport à 1000 par exemple).
Pour référence, j'ai une base qui a 600 000 enregistrements et occupe 100 Mo. Pour la recherche, j'ai extrait certaines colonnes pour obtenir 50 Mo, ce qui réduit le temps de réponse à une durée acceptable. Je pourrais encore réduire ce temps avec des versions indexées en fonction des recherches les plus fréquentes.
Denis
Nicolas
"Denis Beauregard" a écrit dans le message de news:
Le Mon, 2 Jun 2008 14:46:55 +0200, "Xavier" écrivait dans fr.comp.applications.sgbd:
Pour référence, j'ai une base qui a 600 000 enregistrements et occupe 100 Mo. Pour la recherche, j'ai extrait certaines colonnes pour obtenir 50 Mo, ce qui réduit le temps de réponse à une durée acceptable. Je pourrais encore réduire ce temps avec des versions indexées en fonction des recherches les plus fréquentes.
Merci Denis, c'est niquel alors,
Je n'aurais que 2 - 3 colonnes je fais une recherche et dès que j'ai l'enregistrement que je veux, je fais une autre requete sur une autre table.
Si le site cartonne j'aurais le temps de voir venir alors...
merci
"Denis Beauregard" <denis.b-at-francogene.com.invalid@nospam.com.invalid> a
écrit dans le message de news: a0t744dblntkn08s7cie8ibpm1ud3fonb4@4ax.com...
Le Mon, 2 Jun 2008 14:46:55 +0200, "Xavier" <xav1980@nospamsvp.com>
écrivait dans fr.comp.applications.sgbd:
Pour référence, j'ai une base qui a 600 000 enregistrements et
occupe 100 Mo. Pour la recherche, j'ai extrait certaines colonnes
pour obtenir 50 Mo, ce qui réduit le temps de réponse à une durée
acceptable. Je pourrais encore réduire ce temps avec des versions
indexées en fonction des recherches les plus fréquentes.
Merci Denis, c'est niquel alors,
Je n'aurais que 2 - 3 colonnes je fais une recherche et dès que j'ai
l'enregistrement que je veux, je fais une autre requete sur une autre table.
Si le site cartonne j'aurais le temps de voir venir alors...
"Denis Beauregard" a écrit dans le message de news:
Le Mon, 2 Jun 2008 14:46:55 +0200, "Xavier" écrivait dans fr.comp.applications.sgbd:
Pour référence, j'ai une base qui a 600 000 enregistrements et occupe 100 Mo. Pour la recherche, j'ai extrait certaines colonnes pour obtenir 50 Mo, ce qui réduit le temps de réponse à une durée acceptable. Je pourrais encore réduire ce temps avec des versions indexées en fonction des recherches les plus fréquentes.
Merci Denis, c'est niquel alors,
Je n'aurais que 2 - 3 colonnes je fais une recherche et dès que j'ai l'enregistrement que je veux, je fais une autre requete sur une autre table.
Si le site cartonne j'aurais le temps de voir venir alors...
