Methode pour l'enregistrement et recherche de donnée dans une DB ?? - Algo - Programmation
Marsh Posté le 20-09-2002 à 13:01:27
Drôle de boîte que la tienne !
Ils veulent pas non plus que ton programme interroge les données à partir d'un classeur et des feuilles volantes ???
Si ta boîte ne veut pas investir dans un SGBD, soit, mais dans ce cas, tu as MySql
Tu pourrais gérer les données via une base sous MySql, ton programme bossant sur la base grâce à la lib que tu peux trouver ici http://libdbi.sourceforge.net/
C'est une lib de Data Base Interface, ça permet à ton prog en C de communiquer avec un SGBD en lecture, écriture, mise à jour, etc ...
Et en +, la lib permet déjà de faire des programmes C bossant justement avec MySql
Marsh Posté le 20-09-2002 à 13:03:12
Aricoh a écrit a écrit : Drôle de boîte que la tienne ! Ils veulent pas non plus que ton programme interroge les données à partir d'un classeur et des feuilles volantes ??? Si ta boîte ne veut pas investir dans un SGBD, soit, mais dans ce cas, tu as MySql Tu pourrais gérer les données via une base sous MySql, ton programme bossant sur la base grâce à la lib que tu peux trouver ici http://libdbi.sourceforge.net/ C'est une lib de Data Base Interface, ça permet à ton prog en C de communiquer avec un SGBD en lecture, écriture, mise à jour, etc ... Et en +, la lib permet déjà de faire des programmes C bossant justement avec MySql |
Tu as tout a fais raison mais je ne bosse pas dans une boite je suis etudiant je dois faire ca pour les cours et l'interet est de comrpendre le fonctionnement d'une DB au dela des requetes evidement
avec du SQL c simple a faire un annuaire.
Marsh Posté le 20-09-2002 à 13:06:38
ah ok, dans ce cas, pourquoi ne passerais-tu pas par des fichiers DBM (Data Base Management) ???
j'ai appris ces notions lorsque je faisais mes armes en Perl, ce sont des petits fichiers écrits en binaire qui contiennent des données par association clé/valeur
clé/valeur, ça coïnciderait totalement avec la notion en BDD de champ/valeur
Bon, j'ai dit que j'avais vu ça sous Perl mais j'ai également appris que ce type de fichiers de données venait directement du C, donc valà quoi
Marsh Posté le 20-09-2002 à 13:09:49
Merci, mais moi tout ce que j'aimerais comprendre c'est la methode utilisée pour la recherche de données.
En SQL lorsque tu fais un SELECT champ FROM table WHERE champ2 LIKE '%texte%'
par exemple ... ou meme plus simplement un SELECT * FROM table WHERE champ='text'
comment les données sont receuillie ? Si une DB n'est pas tres grosse, si on parcours tout le fichier , ya pas de probleme on verra pas de ralenteissement, mais dans le cas d'un annuaire qui est prevu pour contenir des millions d'enregistrements, on ne peut pas parcourir tout le fichier a chaque recherche?? ca me parrait insencé...
a+
Marsh Posté le 20-09-2002 à 13:19:25
Schtroumpheur a écrit a écrit : Merci, mais moi tout ce que j'aimerais comprendre c'est la methode utilisée pour la recherche de données. En SQL lorsque tu fais un SELECT champ FROM table WHERE champ2 LIKE '%texte%' par exemple ... ou meme plus simplement un SELECT * FROM table WHERE champ='text' comment les données sont receuillie ? Si une DB n'est pas tres grosse, si on parcours tout le fichier , ya pas de probleme on verra pas de ralenteissement, mais dans le cas d'un annuaire qui est prevu pour contenir des millions d'enregistrements, on ne peut pas parcourir tout le fichier a chaque recherche?? ca me parrait insencé... a+ |
dans un SGBD, c'est le langage interne du SGBD qui optimise la requète SQL pour chopper les enregistrements à retourner. il utilise pour celà des index mais si je prend exemple avec Oracle, il me semble que c'est bourré de codes en ProC dedans
Si tu ne peux pas charger les données en mémoire au lancement du prog, et qu'à chaque fois que tu émuleras une requète SQL, tu dois accéder à de gros fichiers, ben oulà !
Marsh Posté le 20-09-2002 à 13:20:49
Aricoh a écrit a écrit : dans un SGBD, c'est le langage interne du SGBD qui optimise la requète SQL pour chopper les enregistrements à retourner. il utilise pour celà des index mais si je prend exemple avec Oracle, il me semble que c'est bourré de codes en ProC dedans Si tu ne peux pas charger les données en mémoire au lancement du prog, et qu'à chaque fois que tu émuleras une requète SQL, tu dois accéder à de gros fichiers, ben oulà ! |
Ben c possible c pour ca qeu je demande
Je veux jsute connaitre le principe de cela. vala
Marsh Posté le 20-09-2002 à 13:21:43
De toute fcon dans mon projet y aura ptete 100 enregistrements maximum, mais bon faut quand meme que je pense bien mon truc et qu'ils soit pas betement programmé... Car je devrait expliquer toutes les fonction crees, et excpliquer l'analyse , et tout en detail donc si elle me sort "que se passe t'il si la DB fait 3go" je lui repond quoi?? Ha ben j'avais la flemme de bien faire mon prog... pi la y en a que 100 alors boucle la !!!!
non mais voila quoi...
Marsh Posté le 20-09-2002 à 13:24:55
je vais te proposer un truc de ouf
tu pourrais avoir un fichier contenant tes données, ligne par ligne (1 record = 1 ligne)
à côté, un fichier index qui contiendrait des mots-clés renvoyant vers un n° de ligne particulier
au lancement de ton prog, lecture du fichier index que tu place en mémoire, et dès qu'il faut lire une donnée, hop tu ne lis et récupère que la ligne concernée dans ton fichier de données
c'est horrible, n'est-il point ?
Marsh Posté le 20-09-2002 à 13:26:20
Expliques plus en details stp car je ne saisi pas l'interet de faire des mot-clefs?
Merci
Marsh Posté le 20-09-2002 à 13:29:54
Schtroumpheur a écrit a écrit : Expliques plus en details stp car je ne saisi pas l'interet de faire des mot-clefs? Merci |
en fait, j'aurais du dire plusieurs fichiers d'index
chaque fichier d'index contient des mots clés propres à un champ de la base
genre exemple le fichier NOM.txt pourrait ressembler à ça :
DUPONT, 9, 10, 11, 12, 45
mot-clé = un nom d'un gus, ici DUPONT
valeurs suivantes = lignes du fichier de données où NOM == DUPONT
pour écrire de nouvelles données dans ton fichier de data, il suffirait de rajouter des lignes et juste de mettre à jour tes fichiers d'index en rajoutant le n° de la ligne rajoutée
grosso merdo, pour chaque champ de ta pseudo-base, il te faudrait un fichier d'index
Marsh Posté le 20-09-2002 à 13:36:44
Ha ok ! Je vois, il faudrait faire un dictionnaire quoi si le nom DUPOND est deja dans le DICO on ajoute a coté du nom un numero de ligne. Sinon on ajotue le mot plus le n° de ligne ou il se trouve. OK je comprend, mais car il est clair quand dans un annuaire beaucoup de personne on le meme nom on peut dire en moyenne 40 a 50 personne voir plus donc si on a 10 million d'enregistrement ca ferait in dico contenent 10.000.000 / 50, ce qui fait 500.000 mot + les numero de ligne, mais est ce que on va vraiment gagner du temps en faisant ca?
Marsh Posté le 20-09-2002 à 13:38:31
C clair qu'en y reflechissant c'est horrible a programmer
Marsh Posté le 20-09-2002 à 13:42:58
Schtroumpheur a écrit a écrit : mais est ce que on va vraiment gagner du temps en faisant ca? |
bonne question, merci de l'avoir posé
écoute, je n'y connais absolument rien en fichiers binaires, ce que je sais par contre, c'est que la récupération des données s'y fait + vite qu'avec les fichiers txt
supposant celà, je pense donc que tu peux ouvrir un fichier de données en mode "r" via fopen et atteindre rapidos une ligne qui t'interresse, non ?
en reprenant le cas de tes 10 millions d'enregistrements, je pense que ouvrir un fichier binaire en lecture pour toper la ligne 987.914 se ferait plus rapidement que d'ouvrir un fichier texte et de lire les lignes tant qu'on ne trouve pas celle que l'on veut
mais bon, j'dis pitet' une bêtise là, j'sai po
Marsh Posté le 20-09-2002 à 13:51:26
Oui il est clari que nous gagnerons du temps mais est ce que ce gain de temps sera grand ?? ou negligeable...
Enfin bon, apparemment on dirait que je veux taper trop haut sur ce coup la !
MR. Bill gates commeeeent t'as faiiiiiiiiit avec access??? Tu me donne la source siouplé???????
bon ben je vais faire ca autrmement je demanderai a la prof si je peux
Entk merci a toi
Marsh Posté le 20-09-2002 à 13:53:10
Schtroumpheur a écrit a écrit : MR. Bill gates commeeeent t'as faiiiiiiiiit avec access??? Tu me donne la source siouplé??????? |
Tss tss tss, t'as même pas commencé ton code que tu penses déjà à toutes les failles de sécurité que tu veux y mettre ???
Marsh Posté le 20-09-2002 à 13:55:15
Aricoh a écrit a écrit : Tss tss tss, t'as même pas commencé ton code que tu penses déjà à toutes les failles de sécurité que tu veux y mettre ??? |
Marsh Posté le 20-09-2002 à 14:13:33
si j'ai bien compris tu dois pas faire un sgbd générique mais juste un annuaire, j'ai bon ?
Tu n'as qu'a te faire un fichier d'index par ordre alphabetique, et trier tes données a l'insertion.
ex :
Code :
|
Code :
|
Et lors d'une recherche tu commence par lire l'index pour connaitre la plage du fichiers de données dans la quelle rechercher, ca t'evite d'avoir a parcourir l'ensemble.
Marsh Posté le 20-09-2002 à 14:30:35
Tu as des enregistrements qui arrivent
( Champ_A Champ_B Champ_C ) ...
...
BERTH 01 GOOD
AUDOL 07 NIAK
TREY 02 BON
...
Tu doit pouvoir rechercher ces enregistrements
sur les 3 champs
donc tu inséres chaque ligne dans 3 tables
trié selon 1 seul des champs)
L'insertion se fait après avoir repérer l'endroit
ou tu vas insérer (recherche dichotomique, insertion ...)
ça nous donne
table1 (tri champ1)
-----------
AUDOL 07 NIAK
BERTH 01 GOOD
TREY 02 BON
table2 (tri champ2)
-----------
BERTH 01 GOOD
AUDOL 07 NIAK
TREY 02 BON
table3 (tri champ3)
-----------
TREY 02 BON
BERTH 01 GOOD
AUDOL 07 NIAK
A chaque nouvelles lignes tu inséres la ligne au bon endroit
et après recherche dichotomique sur table 1,2 ou 3
selon tri demandé
ça prend de la place sur le disque, c pas élégant,
mais c pas compliqué à gérer / écrire et ça
devrait être pas mal rapide !
En fait tu perds du temps à l'insertion de toutes
ces lignes dans les différentes tables ...
mais après à la consultation ça devient rapide
Bon j'avais sans doute envie d'écrire
Marsh Posté le 20-09-2002 à 17:15:18
lorill a écrit a écrit : si j'ai bien compris tu dois pas faire un sgbd générique mais juste un annuaire, j'ai bon ? Tu n'as qu'a te faire un fichier d'index par ordre alphabetique, et trier tes données a l'insertion. ex :
|
Salut, mais dans l'optique ou j'ai une DB de plusieur Go, pour inserer une ligne au milieu du fichier il faut que je le reecrive, ca va prendre un temps fou.. non?
Marsh Posté le 20-09-2002 à 17:17:12
vttman2 a écrit a écrit : Tu as des enregistrements qui arrivent ( Champ_A Champ_B Champ_C ) ... ... BERTH 01 GOOD AUDOL 07 NIAK TREY 02 BON ... Tu doit pouvoir rechercher ces enregistrements sur les 3 champs donc tu inséres chaque ligne dans 3 tables trié selon 1 seul des champs) L'insertion se fait après avoir repérer l'endroit ou tu vas insérer (recherche dichotomique, insertion ...) ça nous donne table1 (tri champ1) ----------- AUDOL 07 NIAK BERTH 01 GOOD TREY 02 BON table2 (tri champ2) ----------- BERTH 01 GOOD AUDOL 07 NIAK TREY 02 BON table3 (tri champ3) ----------- TREY 02 BON BERTH 01 GOOD AUDOL 07 NIAK A chaque nouvelles lignes tu inséres la ligne au bon endroit et après recherche dichotomique sur table 1,2 ou 3 selon tri demandé ça prend de la place sur le disque, c pas élégant, mais c pas compliqué à gérer / écrire et ça devrait être pas mal rapide ! En fait tu perds du temps à l'insertion de toutes ces lignes dans les différentes tables ... mais après à la consultation ça devient rapide Bon j'avais sans doute envie d'écrire |
J'avais pensé a la recherche dicotomique mais pour ca il faut que ca soit deja trié comme tu dis, et faire 3 fichier avec les meme données ca a pas de sens, d'avoir des données redondante
Merci quand meme
Marsh Posté le 20-09-2002 à 20:49:04
Schtroumpheur a écrit a écrit : Salut, mais dans l'optique ou j'ai une DB de plusieur Go, pour inserer une ligne au milieu du fichier il faut que je le reecrive, ca va prendre un temps fou.. non? |
euh, si.
Marsh Posté le 20-09-2002 à 22:39:29
Marsh Posté le 20-09-2002 à 12:44:24
Bonjour !
Voila...
J'ai un projet de développement a faire en langage C.
Je m'explique, je dois creer un annuaire telephonique, avec le quel nous pourrons effectuer des recherches par nom, par ville, etc... et aussi ajouter-supprimer des enregistrement, bref tout ce qu'il y a de plus classique.
La base de données nous devons la faire nous meme sans access ou quoique ce soit, nous devons utiliser des fichiers !
En fait j'ai reflechis au probleme et je voudrais savoir quelle est la meilleure methode a adopter pour l'enregistrement des fichier? Je pense que dans une DB comme les enregistrements sont effectué en temps reel sur le disque dur, ils s'ajoutent les un a la suite des autres sans etre triés. Si je me trompe merci de me le dire. Bref le prob ne se situe pas la, mais dans la recherche d'enregistrement, j'ai imaginé avoir une DB de 1 ou plusieur giga en taille par exemple, et je ne vois pas d'autre moyen de proceder pour uen recherche que de parcourir tout le fichier. Mais a mon avis ca va mettre un temps fou non??? Alors je fais appel a vous pour savoir s'il y a une methode particuliere a utiliser pour que tout ca soit casi instantané peu importe la taille de la DB ! Il y a qque chose qui m'echape. Y a t'il des algos particulier ??
Merci d'avance pour votre aide .
---------------
J'ai une pierre à la place du coeur, et au milieu de cette pierre il y a un coeur.