Base de donnée en C

Jean-Marc

31/10/2004 à 19:11

"Pascal" a écrit dans le message de
news:41852848$0$16312$

Bonjour,

J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai
choisi cette solution. Ma base de donnée va contenir des contacts. Pour
des raisons de perf, je cherche à lire le plus rapidement possible sur
un fichier texte. On m'a dit que le mettre sous forme binaire
amélirorait ses perfs grace à fread qui permettrait de se positionner où
on veut. Mais est il possible de faire autrement?
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez
vous de cette idée?

Hello,

C'est pour un projet perso je suppose?
Si oui, alors un fichier texte va très bien.

Combien de contacts? 100? 1000? 10.000?
Si c'est moins de 10.000, la encore, ne pas s'inquiéter des perfs.
N'importe quelle machine un peu récente a des performances plus
que suffisantes pour ce genre de choses.

Après, ca dépend de ce que tu veux faire avec ta BDD. Si c'est des
choses basiques comme ajout/supprime/recherche avec telle ou telle
clé, la encore un fichier texte est ok. Pour des choses plus complexes
(requetes multi-criteres, etc.), il faudra considérer quelque chose de
plus dodu (une vrai BDD avec SQL etc.).

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."

Anthony Fleury

31/10/2004 à 19:25

Pascal wrote:

Bonjour,

J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai
choisi cette solution. Ma base de donnée va contenir des contacts. Pour
des raisons de perf, je cherche à lire le plus rapidement possible sur
un fichier texte. On m'a dit que le mettre sous forme binaire
amélirorait ses perfs grace à fread qui permettrait de se positionner où
on veut. Mais est il possible de faire autrement?
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez
vous de cette idée?

Quels en seraient les vraies utilités ? c'est un gros ou un petit projet ?

Un fichier texte suffit si c'est pour garder les contacts d'une personne
normale. Le mettre en binaire pourrait permettre de «naviguer» plus
facilement (aller à un enregistrement précis) dans une seule condition,
avoir des enregistrements de taille fixe, et dans ce cas le texte a aussi
une taille d'enregistrement fixe... freaad() ne permet pas spécialement de
se positionner où on veut, on se positionne où on veut avec fseek() et
ensuite on fait des fread(), mais dans ce cas, le où on veut faut pouvoir
le déterminer (donc par un index ou autre).
Et quant au choix de plusieurs ou un fichier(s), ca dépend surtout du
système d'exploitation et du système de fichier.

En gros, il n'y a rien en C standard pour faire des bases de données, mais
y'a des solutions existantes et des implémentations de SGBD utilisables
(MySQL ou DB sous linux, ODBC sous windows...). Mais faut voir aussi à pas
être trop overkill dans la solution choisie.

Anthony
--
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about as
relevant as the question of whether submarines can swim.
-- Dijkstra

Max Lelubre

31/10/2004 à 19:35

Le Sun, 31 Oct 2004 20:00:37 +0100, Pascal wrote:

J'ai besoin d'une base de donnée pour un programme C.

Package: sqlite
Description: SQLite shared library
SQLite is a C library that implements an SQL database engine.
Programs that link with the SQLite library can have SQL database
access without running a separate RDBMS process.

Google devrait t'aider à trouver le site web du projet.

Je fais cour, bye ;)

Jean-Marc Bourguet

31/10/2004 à 19:45

Pascal writes:

Hello,
C'est pour un projet perso je suppose?
Si oui, alors un fichier texte va très bien.

Non projet scolaire.

Un fichier texte suffit.

Combien de contacts? 100? 1000? 10.000?
Si c'est moins de 10.000, la encore, ne pas s'inquiéter des perfs.
N'importe quelle machine un peu récente a des performances plus
que suffisantes pour ce genre de choses.

En théorie un grand nombre. Pour ma démo, surement une dizaine. Mais il
faudrat aussi faire une analyse des limites de notre sytème.

Si tu veux tu peux parler de Berkeley DB
(http://www.sleepycat.com/) ou même d'interfacage avec de
plus gros machins.

Après, ca dépend de ce que tu veux faire avec ta BDD. Si c'est des
choses basiques comme ajout/supprime/recherche avec telle ou telle
clé, la encore un fichier texte est ok. Pour des choses plus complexes
(requetes multi-criteres, etc.), il faudra considérer quelque chose de
plus dodu (une vrai BDD avec SQL etc.).

Des fonctions basiques. Mais j'aimerais surtout savoir
s'il y avait moyen de d'optimiser tout ça.

Premature optimization is the root of all evil.

Dans un projet scolaire, toute optimisation est prématurée
si l'optimisation n'est pas l'objectif de l'exercice.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc

31/10/2004 à 20:10

"Jean-Marc Bourguet" a écrit dans le message de
news:

Pascal writes:
Premature optimization is the root of all evil.

Dans un projet scolaire, toute optimisation est prématurée
si l'optimisation n'est pas l'objectif de l'exercice.

Tout à fait vrai. Pour un exercice scolaire, le but de ce
genre d'excercice (gestion d'une mini BDD en C pur) est simple:
Voir si tu maîtrises les fonctions C d'accès aux fichiers. Tu
choisis une méthode, peu importe laquelle, et tu expliques les
raisons de ton choix, en expliquant les points forts (par exexmple
facilité d'implémentation, facilité de maintenance du code, rapidité
d'accès aux données, etc) et les faiblesses (grande place disque,
vitesse +/- fonction du nombre d'enregistrements, etc.).

On te jugera aussi bien sur sur la propreté de ton code:
lisibilité, portabilité, utilisation des bonnes méthodes.

Une méthode classique:
- un fichier avec les données (des records de taille fixe)
- un ou des fichiers pour gérer les trous dans le fichier,
les index pour des recherches un peu rapides, etc.

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."

Pascal

31/10/2004 à 20:20

Hello,

C'est pour un projet perso je suppose?
Si oui, alors un fichier texte va très bien.

Non projet scolaire.

Combien de contacts? 100? 1000? 10.000?
Si c'est moins de 10.000, la encore, ne pas s'inquiéter des perfs.
N'importe quelle machine un peu récente a des performances plus
que suffisantes pour ce genre de choses.

En théorie un grand nombre. Pour ma démo, surement une dizaine. Mais il
faudrat aussi faire une analyse des limites de notre sytème.

Après, ca dépend de ce que tu veux faire avec ta BDD. Si c'est des
choses basiques comme ajout/supprime/recherche avec telle ou telle
clé, la encore un fichier texte est ok. Pour des choses plus complexes
(requetes multi-criteres, etc.), il faudra considérer quelque chose de
plus dodu (une vrai BDD avec SQL etc.).

Des fonctions basiques. Mais j'aimerais surtout savoir s'il y avait
moyen de d'optimiser tout ça.

Trognon Patrice

31/10/2004 à 20:34

Pascal wrote:

Bonjour,

J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai
choisi cette solution. Ma base de donnée va contenir des contacts. Pour
des raisons de perf, je cherche à lire le plus rapidement possible sur
un fichier texte. On m'a dit que le mettre sous forme binaire
amélirorait ses perfs grace à fread qui permettrait de se positionner où
on veut. Mais est il possible de faire autrement?
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez
vous de cette idée?

Hi,

Netscape utilise la Berkeley DB pour stocker ses infos de contact/cache
etc, j'ai déjà utilisé c'set rapide efficace, ca s'interface par des apis
relativement simple a utiliser, et vas trouver des interfaces pour le C,
Perl, Java, ainsi que tous les autres languages.

Ca marche sur tous les OS.

C'est free.

C'est une lib que tu link a ton code, au choix en static ou en dynamic.

Voila, a toi de voir.
ATTENTION : ca ne s'interroge pas a partir de SQL, c'est que des APIS.

voici l'url : http://www.sleepycat.com/download/index.shtml

Cordialement,

Patrice Trognon.
http://www.javadevel.com

Emmanuel Delahaye

31/10/2004 à 20:58

Pascal wrote on 31/10/04 :

J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte?

MySQL
PostgreSQL...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Pierre Maurette

31/10/2004 à 22:33

Pascal a écrit:

Bonjour,

J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai
choisi cette solution. Ma base de donnée va contenir des contacts. Pour
des raisons de perf, je cherche à lire le plus rapidement possible sur
un fichier texte. On m'a dit que le mettre sous forme binaire
amélirorait ses perfs grace à fread qui permettrait de se positionner où
on veut. Mais est il possible de faire autrement?
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez
vous de cette idée?
Bien lire l'énoncé/cahier des charges. Partons du principe que le but

est de programmer en C from scratch, donc de ne pas utiliser de
bibliothèque.
Il y a quatre approches possibles en restant simple, mais deux
s'imposent aux deux autres:
1 - Fichier principal unique mode binaire (le mode texte étant
ensisageable). Enregistrements de taille fixe nécessaires, d'où
limitations et pertes.
2 - Un fichier par contact, en mode texte (ici, le mode binaire serait
AMHA une erreur). Pertes importantes selon l'OS, si par exemple les
fichiers sont petits et la taille d'une entrée élevée. On peut
améliorer en zippant à la volée, mais c'est HS. C'est une solution
souple, vous pouvez facilement faire évoluer le traitement de chaque
fiche, par exemple ajouter pour chaque contact de 0 à X mémos, tout en
conservant les procédures d'accès.

Pour la solution 2, vous pourriez penser utiliser uniquement les noms
de fichiers pour vous y retrouver. Ce n'est certainement pas une bonne
solution, de plus les fonctions de répertoire nécessaires n'existent
pas en C standard. Donc, pour les deux solutions, finalement assez
proches, il vous faut gérer au moins un fichier (ou liste) annexe, un
index.
Dans la solution 2, le nom du fichier (ou une partie de ce nom, sans
le chemin, sans l'extension) constituera un identifiant unique
intéressant. Vous aurez besoin d'un fichier annexe par clé d'accès
(nom, telephone par exemple). Vous aurez à créer des fonctions de
fiche : création, effacement définitif, lecture, modification, etc.
Vouis aurez également à créer des fonctions de listes: tris,
insertion, effacement, recherche, etc.
Dans ce canevas, vous pouvez facilement avancer pas à pas, en validant
les fonctions au fur et à mesure.
--
Pierre

Pascal <pascal@spam.org> a écrit:

Bonjour,

J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai
choisi cette solution. Ma base de donnée va contenir des contacts. Pour
des raisons de perf, je cherche à lire le plus rapidement possible sur
un fichier texte. On m'a dit que le mettre sous forme binaire
amélirorait ses perfs grace à fread qui permettrait de se positionner où
on veut. Mais est il possible de faire autrement?
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez
vous de cette idée?
Bien lire l'énoncé/cahier des charges. Partons du principe que le but

est de programmer en C from scratch, donc de ne pas utiliser de
bibliothèque.
Il y a quatre approches possibles en restant simple, mais deux
s'imposent aux deux autres:
1 - Fichier principal unique mode binaire (le mode texte étant
ensisageable). Enregistrements de taille fixe nécessaires, d'où
limitations et pertes.
2 - Un fichier par contact, en mode texte (ici, le mode binaire serait
AMHA une erreur). Pertes importantes selon l'OS, si par exemple les
fichiers sont petits et la taille d'une entrée élevée. On peut
améliorer en zippant à la volée, mais c'est HS. C'est une solution
souple, vous pouvez facilement faire évoluer le traitement de chaque
fiche, par exemple ajouter pour chaque contact de 0 à X mémos, tout en
conservant les procédures d'accès.

Pour la solution 2, vous pourriez penser utiliser uniquement les noms
de fichiers pour vous y retrouver. Ce n'est certainement pas une bonne
solution, de plus les fonctions de répertoire nécessaires n'existent
pas en C standard. Donc, pour les deux solutions, finalement assez
proches, il vous faut gérer au moins un fichier (ou liste) annexe, un
index.
Dans la solution 2, le nom du fichier (ou une partie de ce nom, sans
le chemin, sans l'extension) constituera un identifiant unique
intéressant. Vous aurez besoin d'un fichier annexe par clé d'accès
(nom, telephone par exemple). Vous aurez à créer des fonctions de
fiche : création, effacement définitif, lecture, modification, etc.
Vouis aurez également à créer des fonctions de listes: tris,
insertion, effacement, recherche, etc.
Dans ce canevas, vous pouvez facilement avancer pas à pas, en validant
les fonctions au fur et à mesure.
--
Pierre

Vous avez filtré cet utilisateur ! Consultez son message

Pascal a écrit:

Bonjour,

J'ai besoin d'une base de donnée pour un programme C. Est il possible
d'utiliser autre chose qu'un fichier texte? Sinon pour l'instant, j'ai
choisi cette solution. Ma base de donnée va contenir des contacts. Pour
des raisons de perf, je cherche à lire le plus rapidement possible sur
un fichier texte. On m'a dit que le mettre sous forme binaire
amélirorait ses perfs grace à fread qui permettrait de se positionner où
on veut. Mais est il possible de faire autrement?
Moi j'ai décidé d'implémenter plutot un fichier par contact. Que pensez
vous de cette idée?
Bien lire l'énoncé/cahier des charges. Partons du principe que le but

est de programmer en C from scratch, donc de ne pas utiliser de
bibliothèque.
Il y a quatre approches possibles en restant simple, mais deux
s'imposent aux deux autres:
1 - Fichier principal unique mode binaire (le mode texte étant
ensisageable). Enregistrements de taille fixe nécessaires, d'où
limitations et pertes.
2 - Un fichier par contact, en mode texte (ici, le mode binaire serait
AMHA une erreur). Pertes importantes selon l'OS, si par exemple les
fichiers sont petits et la taille d'une entrée élevée. On peut
améliorer en zippant à la volée, mais c'est HS. C'est une solution
souple, vous pouvez facilement faire évoluer le traitement de chaque
fiche, par exemple ajouter pour chaque contact de 0 à X mémos, tout en
conservant les procédures d'accès.

Pour la solution 2, vous pourriez penser utiliser uniquement les noms
de fichiers pour vous y retrouver. Ce n'est certainement pas une bonne
solution, de plus les fonctions de répertoire nécessaires n'existent
pas en C standard. Donc, pour les deux solutions, finalement assez
proches, il vous faut gérer au moins un fichier (ou liste) annexe, un
index.
Dans la solution 2, le nom du fichier (ou une partie de ce nom, sans
le chemin, sans l'extension) constituera un identifiant unique
intéressant. Vous aurez besoin d'un fichier annexe par clé d'accès
(nom, telephone par exemple). Vous aurez à créer des fonctions de
fiche : création, effacement définitif, lecture, modification, etc.
Vouis aurez également à créer des fonctions de listes: tris,
insertion, effacement, recherche, etc.
Dans ce canevas, vous pouvez facilement avancer pas à pas, en validant
les fonctions au fur et à mesure.
--
Pierre

James Kanze

01/11/2004 à 12:08

Pascal writes:

|> > C'est pour un projet perso je suppose?
|> > Si oui, alors un fichier texte va très bien.

|> Non projet scolaire.

Quel est le but du projet ? C-à-d est-ce que la base de données est
accessoire, ou est-ce que le but est que tu programmes toi-même une
petite base de données ? Dans le premier cas, l'utilisation d'une
bibliothèque tout faite me semble tout à fait indiquée, dans le
deuxième, c'est évidemment interdit. Dans le deuxième cas, en revanche,
il faudrait d'avantage d'informations : combien d'enrégistrements,
critères d'accès et de mise à jour, etc. Dans le cadre d'un projet
scholaire, tu n'arriveras pas à implémenter quelque chose du genre SQL ;
il faut donc savoir ce qu'il faut sabrer.

|> > Combien de contacts? 100? 1000? 10.000? Si c'est moins de 10.000,
|> > la encore, ne pas s'inquiéter des perfs. N'importe quelle machine
|> > un peu récente a des performances plus que suffisantes pour ce
|> > genre de choses.

|> En théorie un grand nombre. Pour ma démo, surement une dizaine. Mais
|> il faudrat aussi faire une analyse des limites de notre sytème.

Un premier choix de taille : est-ce qu'on peut maintenir toutes les
données en mémoire ou non ? (Avec des machines modernes, la limite
pourrait bien être à plus d'une million d'enregistrements.) Et quel sont
les contraints de robustité : que se passe-t-il par exemple si ton
programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?

|> > Après, ca dépend de ce que tu veux faire avec ta BDD. Si c'est des
|> > choses basiques comme ajout/supprime/recherche avec telle ou telle
|> > clé, la encore un fichier texte est ok. Pour des choses plus
|> > complexes (requetes multi-criteres, etc.), il faudra considérer
|> > quelque chose de plus dodu (une vrai BDD avec SQL etc.).

|> Des fonctions basiques. Mais j'aimerais surtout savoir s'il y avait
|> moyen de d'optimiser tout ça.

Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
général l'optimisation la plus importante), la vitesse d'exécution,
l'utilisation mémoire (qui joue aussi sur la vitesse -- plus tu tiens en
mémoire, plus la récherche sera rapide) ; typiquement, en fait, la
première démarche d'optimisation d'un tel programme, c'est de
s'organiser pour maintenir le plus possible en mémoire.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Pascal <pascal@spam.org> writes:

|> > C'est pour un projet perso je suppose?
|> > Si oui, alors un fichier texte va très bien.

|> Non projet scolaire.

Quel est le but du projet ? C-à-d est-ce que la base de données est
accessoire, ou est-ce que le but est que tu programmes toi-même une
petite base de données ? Dans le premier cas, l'utilisation d'une
bibliothèque tout faite me semble tout à fait indiquée, dans le
deuxième, c'est évidemment interdit. Dans le deuxième cas, en revanche,
il faudrait d'avantage d'informations : combien d'enrégistrements,
critères d'accès et de mise à jour, etc. Dans le cadre d'un projet
scholaire, tu n'arriveras pas à implémenter quelque chose du genre SQL ;
il faut donc savoir ce qu'il faut sabrer.

|> > Combien de contacts? 100? 1000? 10.000? Si c'est moins de 10.000,
|> > la encore, ne pas s'inquiéter des perfs. N'importe quelle machine
|> > un peu récente a des performances plus que suffisantes pour ce
|> > genre de choses.

|> En théorie un grand nombre. Pour ma démo, surement une dizaine. Mais
|> il faudrat aussi faire une analyse des limites de notre sytème.

Un premier choix de taille : est-ce qu'on peut maintenir toutes les
données en mémoire ou non ? (Avec des machines modernes, la limite
pourrait bien être à plus d'une million d'enregistrements.) Et quel sont
les contraints de robustité : que se passe-t-il par exemple si ton
programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?

|> > Après, ca dépend de ce que tu veux faire avec ta BDD. Si c'est des
|> > choses basiques comme ajout/supprime/recherche avec telle ou telle
|> > clé, la encore un fichier texte est ok. Pour des choses plus
|> > complexes (requetes multi-criteres, etc.), il faudra considérer
|> > quelque chose de plus dodu (une vrai BDD avec SQL etc.).

|> Des fonctions basiques. Mais j'aimerais surtout savoir s'il y avait
|> moyen de d'optimiser tout ça.

Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
général l'optimisation la plus importante), la vitesse d'exécution,
l'utilisation mémoire (qui joue aussi sur la vitesse -- plus tu tiens en
mémoire, plus la récherche sera rapide) ; typiquement, en fait, la
première démarche d'optimisation d'un tel programme, c'est de
s'organiser pour maintenir le plus possible en mémoire.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Pascal writes:

|> > C'est pour un projet perso je suppose?
|> > Si oui, alors un fichier texte va très bien.

|> Non projet scolaire.

Quel est le but du projet ? C-à-d est-ce que la base de données est
accessoire, ou est-ce que le but est que tu programmes toi-même une
petite base de données ? Dans le premier cas, l'utilisation d'une
bibliothèque tout faite me semble tout à fait indiquée, dans le
deuxième, c'est évidemment interdit. Dans le deuxième cas, en revanche,
il faudrait d'avantage d'informations : combien d'enrégistrements,
critères d'accès et de mise à jour, etc. Dans le cadre d'un projet
scholaire, tu n'arriveras pas à implémenter quelque chose du genre SQL ;
il faut donc savoir ce qu'il faut sabrer.

|> > Combien de contacts? 100? 1000? 10.000? Si c'est moins de 10.000,
|> > la encore, ne pas s'inquiéter des perfs. N'importe quelle machine
|> > un peu récente a des performances plus que suffisantes pour ce
|> > genre de choses.

|> En théorie un grand nombre. Pour ma démo, surement une dizaine. Mais
|> il faudrat aussi faire une analyse des limites de notre sytème.

Un premier choix de taille : est-ce qu'on peut maintenir toutes les
données en mémoire ou non ? (Avec des machines modernes, la limite
pourrait bien être à plus d'une million d'enregistrements.) Et quel sont
les contraints de robustité : que se passe-t-il par exemple si ton
programme crashe, ou qu'on tire le cordon de l'ordinateur par erreur ?

|> > Après, ca dépend de ce que tu veux faire avec ta BDD. Si c'est des
|> > choses basiques comme ajout/supprime/recherche avec telle ou telle
|> > clé, la encore un fichier texte est ok. Pour des choses plus
|> > complexes (requetes multi-criteres, etc.), il faudra considérer
|> > quelque chose de plus dodu (une vrai BDD avec SQL etc.).

|> Des fonctions basiques. Mais j'aimerais surtout savoir s'il y avait
|> moyen de d'optimiser tout ça.

Optimiser quoi dans tout ça ? Le temps de programmation (c'est en
général l'optimisation la plus importante), la vitesse d'exécution,
l'utilisation mémoire (qui joue aussi sur la vitesse -- plus tu tiens en
mémoire, plus la récherche sera rapide) ; typiquement, en fait, la
première démarche d'optimisation d'un tel programme, c'est de
s'organiser pour maintenir le plus possible en mémoire.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Base de donnée en C

10 réponses

Veuillez sélectionner un problème