Discussion :

[dibejmaher]

salut

j'ai une question si quelqu'un peut m'aidé
j'ai une table ou y a plus que 3 700 000 lignie

et je ve voudrai faire quelque statistique a partir de cette table
nombre d'occurence d'un client
nombre de nouveau clien par intervalle de temps

alors je me demande si il vaudra mieux faire une requette sql et laissé les sgbd se debrouillé (avec quelque test j'ai trouvé qu'il se plante tout le temps )

ou exporté cette table et faire un program en C avec des algorithme de recherche

je cherche la solution optimal pour le system pour diminué les calcul

vous me conseillez quoi ?

[PRomu@ld]

(avec quelque test j'ai trouvé qu'il se plante tout le temps )

En fait, je vois pas pourquoi le SGBD ferait des erreurs ? Ou alors tu parles de plantage logiciel (manque de mémoire ou qlq chose du genre ...)

Est ce que tes recherches ne sont que celles que tu as donnés ? (ou il y en a d'autres plus compliqués ?)

[dibejmaher]

Ou alors tu parles de plantage logiciel (manque de mémoire ou qlq chose du genre ...)

oui je parle de sa en effet

voila ce que je veux chercher au juste de savoir combien j'ai de client pas d'achat donc si un CIN ce répete sa veux dir qu'on le compte qu'une seul foit

dans une periode de temps donné on a gagnié combien de nouveau client

alors que notre table n'est pas trié

mon idee et de faire exporté la table la trié puit faire les operation de rechérche si dessut

[buzard]

C'est l'avantage de payer un ingénieur pour faire une etude préalable, avant de construire betement une seule table avec toute les infos. En générale si on s'y prend bien on arrive à une structure bien fondé, à partir de laquel le sgbd peu faire de bonnes optimisations.

Si ta table est trop grosse, pense à faire du filtrage, (en base et pas à la fin) evite les jointures (ou alors avec des tables raisonnables et bien indéxées). Ainsi tu peu découper ton analyse en plusieurs morceaux, puis recoller les informations.

Si vraiment ca marche pas. découpe ta table en plusieurs morceaux (à faire tourner sur des instance différente du sgbd, le mieux c'est sur une autre machine).

[random]

il n'est pas nécessaire d'être ingénieur pour des choses aussi basiques
d'une façon générale sql fera toujours mieux que tes programmes en c
et sera plus performant
surtout si tu indexes un peu
si ta base met réellement ton sgbd à genoux et que tu ne peux pas l'optimiser
(historisation, compactage, optimisation de la taille des champs ) il faut probablement te dire que tu dépasses les limites de ton sgdb et qu'il est temps d'en changer
il serait utile de nous indiquer la taille de la base et le sgbd employé

[buzard]

d'une façon générale sql fera toujours mieux que tes programmes en c et sera plus performant

Je ne suis pas d'accord, un sgbd c'est une grosse usine à gaz. Et les temps de réaction seront toujours mions bons que l'utilisation du système de fichier. On y perdra certe en structuration et interface d'access, mais on y gagnera en volume et en vitesse.
Bon c'est vrai que ce n'est applicable concrètement que pour des données trés simples (évolution d'un ou plusieurs indice dans le temps, suivi d'un ou plusieurs capteur, listes simple, ...). Puisque sinon ça revient à prendre en considération les références, et donc à réécrire un sgbd.

[borisd]

voila ce que je veux chercher au juste de savoir combien j'ai de client pas d'achat donc si un CIN ce répete sa veux dir qu'on le compte qu'une seul foit

Tu connais "SELECT DISTINCT" en SQL? Ce n'est pas ça que tu cherches à faire ?