Je cherche a developper une appli qui gere une base de donnees.
Le probleme c'est le format de la base de donnée.
jusqu'a present c'etait en foxpro DBF.
Maintanant je ne sais pas quoi prendre.
Avez vous une piste ?
Merci de votre aide.
--
Probleme non resolu sous linux:
1) Comment mettre un quota sur la corbeille pour eviter la saturation des disques avec FIFO automatique ?
2) Pourquoi ne peut on pas decaler une partition ext3 en empietant sur elle meme ? NTFS ne bronche pas dans un cas comme celui là.
3) -
4) -
Voila ma question : Je cherche a developper une appli qui gere une base de donnees. Le probleme c'est le format de la base de donnée. jusqu'a present c'etait en foxpro DBF. Maintanant je ne sais pas quoi prendre.
Il y a plein de facteurs à prendre en compte (nb enreg, client-serveur ou non, etc...) MSDE parmi d'autres
Le chat de personne wrote:
Bonjour
Voila ma question :
Je cherche a developper une appli qui gere une base de donnees.
Le probleme c'est le format de la base de donnée.
jusqu'a present c'etait en foxpro DBF.
Maintanant je ne sais pas quoi prendre.
Il y a plein de facteurs à prendre en compte (nb enreg, client-serveur
ou non, etc...)
MSDE parmi d'autres
Voila ma question : Je cherche a developper une appli qui gere une base de donnees. Le probleme c'est le format de la base de donnée. jusqu'a present c'etait en foxpro DBF. Maintanant je ne sais pas quoi prendre.
Il y a plein de facteurs à prendre en compte (nb enreg, client-serveur ou non, etc...) MSDE parmi d'autres
Le chat de personne
On Sun, 29 Apr 2007 18:09:57 +0200, jerome wrote:
Le chat de personne wrote:
Bonjour
Voila ma question : Je cherche a developper une appli qui gere une base de donnees. Le probleme c'est le format de la base de donnée. jusqu'a present c'etait en foxpro DBF. Maintanant je ne sais pas quoi prendre.
Il y a plein de facteurs à prendre en compte (nb enreg, client-serveur ou non, etc...) MSDE parmi d'autres
Ben j'ai pas de serveur.
On peut creer une base avec sql ?si oui, de qu'elle format est ce ? (dbf, xml,...)
De toute facon ce que je veux c'est que la base de donnee soit dans le repertoire du programme executable pour etre facilement exportable. Cet executable devra etre le plus independant possible. A la rigueur l'installe d'un moteur de gestion de base de donnees et c'est tout.
Le format de bdd doit etre aussi simple (pas de compression des donnees) pour eviter d'alourdir le temps de traitement.
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par enregistrement)
On Sun, 29 Apr 2007 18:09:57 +0200, jerome <jerome@parsys.com> wrote:
Le chat de personne wrote:
Bonjour
Voila ma question :
Je cherche a developper une appli qui gere une base de donnees.
Le probleme c'est le format de la base de donnée.
jusqu'a present c'etait en foxpro DBF.
Maintanant je ne sais pas quoi prendre.
Il y a plein de facteurs à prendre en compte (nb enreg, client-serveur
ou non, etc...)
MSDE parmi d'autres
Ben j'ai pas de serveur.
On peut creer une base avec sql ?si oui, de qu'elle format est ce ?
(dbf, xml,...)
De toute facon ce que je veux c'est que la base de donnee soit dans le
repertoire du programme executable pour etre facilement exportable.
Cet executable devra etre le plus independant possible. A la rigueur
l'installe d'un moteur de gestion de base de donnees et c'est tout.
Le format de bdd doit etre aussi simple (pas de compression des
donnees) pour eviter d'alourdir le temps de traitement.
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par
enregistrement)
Voila ma question : Je cherche a developper une appli qui gere une base de donnees. Le probleme c'est le format de la base de donnée. jusqu'a present c'etait en foxpro DBF. Maintanant je ne sais pas quoi prendre.
Il y a plein de facteurs à prendre en compte (nb enreg, client-serveur ou non, etc...) MSDE parmi d'autres
Ben j'ai pas de serveur.
On peut creer une base avec sql ?si oui, de qu'elle format est ce ? (dbf, xml,...)
De toute facon ce que je veux c'est que la base de donnee soit dans le repertoire du programme executable pour etre facilement exportable. Cet executable devra etre le plus independant possible. A la rigueur l'installe d'un moteur de gestion de base de donnees et c'est tout.
Le format de bdd doit etre aussi simple (pas de compression des donnees) pour eviter d'alourdir le temps de traitement.
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par enregistrement)
Christian ASTOR
Le chat de personne wrote:
Je cherche a developper une appli qui gere une base de donnees.
Le probleme c'est le format de la base de donnée.
jusqu'a present c'etait en foxpro DBF.
Maintanant je ne sais pas quoi prendre.
Avez vous une piste ?
Par ex, http://msdn.microsoft.com/vstudio/express/sql/
Le chat de personne wrote:
Je cherche a developper une appli qui gere une base de donnees.
Le probleme c'est le format de la base de donnée.
jusqu'a present c'etait en foxpro DBF.
Maintanant je ne sais pas quoi prendre.
Avez vous une piste ?
Par ex,
http://msdn.microsoft.com/vstudio/express/sql/
On Sun, 29 Apr 2007 22:11:08 +0200, Christian ASTOR wrote:
Le chat de personne wrote:
Je cherche a developper une appli qui gere une base de donnees.
Le probleme c'est le format de la base de donnée.
jusqu'a present c'etait en foxpro DBF.
Maintanant je ne sais pas quoi prendre.
Avez vous une piste ?
Par ex, http://msdn.microsoft.com/vstudio/express/sql/
J'ai un site perso avec mysql et PHP, mais je trouve que le principe de la base en sql est trop lourd.
J'aimerai que la base soit dans le meme repertoire que l'executable et pas planqué au fin fond d'un autre repertoire hebergeant.
J'aimerai pouvoir l'embarquer sur une clé USB. par exemple.
Enfin je me trompe peut etre.
Remi THOMAS
"Le chat de personne" écrivit
J'ai un site perso avec mysql et PHP, mais je trouve que le principe de la base en sql est trop lourd.
J'aimerai que la base soit dans le meme repertoire que l'executable et pas planqué au fin fond d'un autre repertoire hebergeant.
J'aimerai pouvoir l'embarquer sur une clé USB. par exemple.
Enfin je me trompe peut etre.
Bonjour, SQLite (gratuit) ou si tu es en .NET VistaDB 3.0 (syntaxe 100% compatible SQL Server) Les deux sont des mini moteurs qui ne nécessitent rien d'autre qu'une DLL comme déploiement.
Rémi
"Le chat de personne" écrivit
J'ai un site perso avec mysql et PHP, mais je trouve que le principe
de la base en sql est trop lourd.
J'aimerai que la base soit dans le meme repertoire que l'executable et
pas planqué au fin fond d'un autre repertoire hebergeant.
J'aimerai pouvoir l'embarquer sur une clé USB. par exemple.
Enfin je me trompe peut etre.
Bonjour,
SQLite (gratuit) ou si tu es en .NET VistaDB 3.0 (syntaxe 100% compatible
SQL Server)
Les deux sont des mini moteurs qui ne nécessitent rien d'autre qu'une DLL
comme déploiement.
J'ai un site perso avec mysql et PHP, mais je trouve que le principe de la base en sql est trop lourd.
J'aimerai que la base soit dans le meme repertoire que l'executable et pas planqué au fin fond d'un autre repertoire hebergeant.
J'aimerai pouvoir l'embarquer sur une clé USB. par exemple.
Enfin je me trompe peut etre.
Bonjour, SQLite (gratuit) ou si tu es en .NET VistaDB 3.0 (syntaxe 100% compatible SQL Server) Les deux sont des mini moteurs qui ne nécessitent rien d'autre qu'une DLL comme déploiement.
Rémi
Vincent Burel
"Le chat de personne" wrote in message news:
On Sun, 29 Apr 2007 18:09:57 +0200, jerome wrote:
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par enregistrement)
Ca dépend de ce que vous faites avec, et des contraintes que vous avez dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement un fichier structuré classique (que l'on peut même mapper en mémoire).
VB
"Le chat de personne" <chat@LeSpamCestPasBien.invalid> wrote in message
news:kfr933l9sfso6fv40qc56s42a554ho9mbf@4ax.com...
On Sun, 29 Apr 2007 18:09:57 +0200, jerome <jerome@parsys.com> wrote:
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par
enregistrement)
Ca dépend de ce que vous faites avec, et des contraintes que vous avez
dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement un
fichier structuré classique (que l'on peut même mapper en mémoire).
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par enregistrement)
Ca dépend de ce que vous faites avec, et des contraintes que vous avez dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement un fichier structuré classique (que l'on peut même mapper en mémoire).
VB
Le chat de personne
On Mon, 30 Apr 2007 08:07:08 +0200, "Remi THOMAS" wrote:
SQLite (gratuit) ou si tu es en .NET VistaDB 3.0 (syntaxe 100% compatible SQL Server)
Non sous 2000 et XP sur le PC que je vais utiliser pour ca.
Les deux sont des mini moteurs qui ne nécessitent rien d'autre qu'une DLL comme déploiement.
On Mon, 30 Apr 2007 08:07:08 +0200, "Remi THOMAS" wrote:
SQLite (gratuit) ou si tu es en .NET VistaDB 3.0 (syntaxe 100% compatible SQL Server)
Non sous 2000 et XP sur le PC que je vais utiliser pour ca.
Les deux sont des mini moteurs qui ne nécessitent rien d'autre qu'une DLL comme déploiement.
Ok je vais voir. merci
Le chat de personne
On Mon, 30 Apr 2007 09:21:35 +0200, "Vincent Burel" wrote:
"Le chat de personne" wrote in message news:
On Sun, 29 Apr 2007 18:09:57 +0200, jerome wrote:
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par enregistrement)
Ca dépend de ce que vous faites avec, et des contraintes que vous avez dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement un fichier structuré classique (que l'on peut même mapper en mémoire).
VB
surtout que les 50.000 c'est pour dans 10 ans.....
Donc un fichier classique structuré du genre.....? DBF c'est pas trop prehistorique par exemple ? Ou sinon un autre truc "securisé aux plantages" ca existe (je suis ouvert a tout)
"Le chat de personne" <chat@LeSpamCestPasBien.invalid> wrote in message
news:kfr933l9sfso6fv40qc56s42a554ho9mbf@4ax.com...
On Sun, 29 Apr 2007 18:09:57 +0200, jerome <jerome@parsys.com> wrote:
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par
enregistrement)
Ca dépend de ce que vous faites avec, et des contraintes que vous avez
dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement un
fichier structuré classique (que l'on peut même mapper en mémoire).
VB
surtout que les 50.000 c'est pour dans 10 ans.....
Donc un fichier classique structuré du genre.....?
DBF c'est pas trop prehistorique par exemple ?
Ou sinon un autre truc "securisé aux plantages" ca existe (je suis
ouvert a tout)
On Mon, 30 Apr 2007 09:21:35 +0200, "Vincent Burel" wrote:
"Le chat de personne" wrote in message news:
On Sun, 29 Apr 2007 18:09:57 +0200, jerome wrote:
En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par enregistrement)
Ca dépend de ce que vous faites avec, et des contraintes que vous avez dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement un fichier structuré classique (que l'on peut même mapper en mémoire).
VB
surtout que les 50.000 c'est pour dans 10 ans.....
Donc un fichier classique structuré du genre.....? DBF c'est pas trop prehistorique par exemple ? Ou sinon un autre truc "securisé aux plantages" ca existe (je suis ouvert a tout)
Vincent Burel
"Le chat de personne" wrote in message news:
On Mon, 30 Apr 2007 09:21:35 +0200, "Vincent Burel" wrote:
> >"Le chat de personne" wrote in message >news: >> On Sun, 29 Apr 2007 18:09:57 +0200, jerome wrote: >> > >> En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par >> enregistrement) > >Ca dépend de ce que vous faites avec, et des contraintes que vous avez >dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement
un
>fichier structuré classique (que l'on peut même mapper en mémoire). > >VB
surtout que les 50.000 c'est pour dans 10 ans.....
Donc un fichier classique structuré du genre.....?
Ben du genre vous faite un typedef struct qui défini votre fiche et vous gérez un tableau linéaire de cette structure dans un fichier classique par CreateFile/ReadFile/WriteFile etc... C'est quand même le B-A-BA. Bientôt on verra des gars chercher des librairies pour gérer 500 ko de int en RAM.
DBF c'est pas trop prehistorique par exemple ?
C'est pas une question de préhistoire , c'est une question de savoir quel niveau de control vous voulez avoir sur votre appli, quel niveau d'indépendance.
Ou sinon un autre truc "securisé aux plantages" ca existe (je suis ouvert a tout)
ha dans ce cas là il faut faire une gestion de fichier genre transactionnelle, donc un double fichier avec un troisième qui dit où est-ce qu'on en est... c'est moins trivial, mais ca commence à etre intéressant...
VB
"Le chat de personne" <chat@LeSpamCestPasBien.invalid> wrote in message
news:4eec335dnvojsrfpurou692l0mn8uvb2k2@4ax.com...
>
>"Le chat de personne" <chat@LeSpamCestPasBien.invalid> wrote in message
>news:kfr933l9sfso6fv40qc56s42a554ho9mbf@4ax.com...
>> On Sun, 29 Apr 2007 18:09:57 +0200, jerome <jerome@parsys.com> wrote:
>>
>
>> En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par
>> enregistrement)
>
>Ca dépend de ce que vous faites avec, et des contraintes que vous avez
>dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement
un
>fichier structuré classique (que l'on peut même mapper en mémoire).
>
>VB
surtout que les 50.000 c'est pour dans 10 ans.....
Donc un fichier classique structuré du genre.....?
Ben du genre vous faite un typedef struct qui défini votre fiche et vous
gérez un tableau linéaire de cette structure dans un fichier classique par
CreateFile/ReadFile/WriteFile etc... C'est quand même le B-A-BA. Bientôt on
verra des gars chercher des librairies pour gérer 500 ko de int en RAM.
DBF c'est pas trop prehistorique par exemple ?
C'est pas une question de préhistoire , c'est une question de savoir quel
niveau de control vous voulez avoir sur votre appli, quel niveau
d'indépendance.
Ou sinon un autre truc "securisé aux plantages" ca existe (je suis
ouvert a tout)
ha dans ce cas là il faut faire une gestion de fichier genre
transactionnelle, donc un double fichier avec un troisième qui dit où est-ce
qu'on en est... c'est moins trivial, mais ca commence à etre intéressant...
On Mon, 30 Apr 2007 09:21:35 +0200, "Vincent Burel" wrote:
> >"Le chat de personne" wrote in message >news: >> On Sun, 29 Apr 2007 18:09:57 +0200, jerome wrote: >> > >> En ce moment 20.000 enregistremet et en prevision 50.000 (1ko par >> enregistrement) > >Ca dépend de ce que vous faites avec, et des contraintes que vous avez >dessus, mais 50.000 fiches, ca fait 50 Mo, ca peut etre tout simplement
un
>fichier structuré classique (que l'on peut même mapper en mémoire). > >VB
surtout que les 50.000 c'est pour dans 10 ans.....
Donc un fichier classique structuré du genre.....?
Ben du genre vous faite un typedef struct qui défini votre fiche et vous gérez un tableau linéaire de cette structure dans un fichier classique par CreateFile/ReadFile/WriteFile etc... C'est quand même le B-A-BA. Bientôt on verra des gars chercher des librairies pour gérer 500 ko de int en RAM.
DBF c'est pas trop prehistorique par exemple ?
C'est pas une question de préhistoire , c'est une question de savoir quel niveau de control vous voulez avoir sur votre appli, quel niveau d'indépendance.
Ou sinon un autre truc "securisé aux plantages" ca existe (je suis ouvert a tout)
ha dans ce cas là il faut faire une gestion de fichier genre transactionnelle, donc un double fichier avec un troisième qui dit où est-ce qu'on en est... c'est moins trivial, mais ca commence à etre intéressant...
VB
Le chat de personne
On Tue, 1 May 2007 11:14:43 +0200, "Vincent Burel" wrote:
DBF c'est pas trop prehistorique par exemple ?
C'est pas une question de préhistoire , c'est une question de savoir quel niveau de control vous voulez avoir sur votre appli, quel niveau d'indépendance.
Ben j'en sais rien parce que pour moi ca me parle pas.
Moi je cherche un format non compressé, dont les fichier sont dans le meme repertoire que l'executable (par exemple), que l'executable integre tout ce qu'il faut pour gerer lui meme sans avoir a installer une seule dll (sauf si c'est une dll qui se trouve dans le repertoire de l'executable, avec possibilité de creer des fichiers d'index independant, que je puisse mettre sur une clé usb, un format de la base qui soit standart et pas un format exotique (pour facilité l'import depuis access, approach,...
Voila quoi.
On Tue, 1 May 2007 11:14:43 +0200, "Vincent Burel"
<vincent.burel@nospam.wanadoo.fr> wrote:
DBF c'est pas trop prehistorique par exemple ?
C'est pas une question de préhistoire , c'est une question de savoir quel
niveau de control vous voulez avoir sur votre appli, quel niveau
d'indépendance.
Ben j'en sais rien parce que pour moi ca me parle pas.
Moi je cherche un format non compressé,
dont les fichier sont dans le meme repertoire que l'executable (par
exemple),
que l'executable integre tout ce qu'il faut pour gerer lui meme sans
avoir a installer une seule dll (sauf si c'est une dll qui se trouve
dans le repertoire de l'executable,
avec possibilité de creer des fichiers d'index independant,
que je puisse mettre sur une clé usb,
un format de la base qui soit standart et pas un format exotique (pour
facilité l'import depuis access, approach,...
On Tue, 1 May 2007 11:14:43 +0200, "Vincent Burel" wrote:
DBF c'est pas trop prehistorique par exemple ?
C'est pas une question de préhistoire , c'est une question de savoir quel niveau de control vous voulez avoir sur votre appli, quel niveau d'indépendance.
Ben j'en sais rien parce que pour moi ca me parle pas.
Moi je cherche un format non compressé, dont les fichier sont dans le meme repertoire que l'executable (par exemple), que l'executable integre tout ce qu'il faut pour gerer lui meme sans avoir a installer une seule dll (sauf si c'est une dll qui se trouve dans le repertoire de l'executable, avec possibilité de creer des fichiers d'index independant, que je puisse mettre sur une clé usb, un format de la base qui soit standart et pas un format exotique (pour facilité l'import depuis access, approach,...
