Bonjour, je suis débutant sur le développement sous visual basic, en
je développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
comment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil
Bonjour, je suis débutant sur le développement sous visual basic, en
je développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
comment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil
Bonjour, je suis débutant sur le développement sous visual basic, en
je développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
comment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil
"Julien" a écrit dans le message de
news:Bonjour, je suis débutant sur le développement sous visual basic, en
généralje développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
sais pascomment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil
Hello,
peux tu préciser un peu?
Tu veux:
- Créer une base: pas ouvrir une existante, mais la créer?
Tu veux donc ensuite créer tes tables, les index, etc?
Est ce bien cela?
Car en général, on créé la base avec Access, et le programme VB
se contente de la manipuler.
A moins que tu veuilles faire un programme dont le but est
justement de CREER des bases de données ?
--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
"Julien" <tazou@hotmail.com> a écrit dans le message de
news:eFDnv0FOGHA.420@tk2msftngp13.phx.gbl...
Bonjour, je suis débutant sur le développement sous visual basic, en
général
je développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
sais pas
comment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil
Hello,
peux tu préciser un peu?
Tu veux:
- Créer une base: pas ouvrir une existante, mais la créer?
Tu veux donc ensuite créer tes tables, les index, etc?
Est ce bien cela?
Car en général, on créé la base avec Access, et le programme VB
se contente de la manipuler.
A moins que tu veuilles faire un programme dont le but est
justement de CREER des bases de données ?
--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
"Julien" a écrit dans le message de
news:Bonjour, je suis débutant sur le développement sous visual basic, en
généralje développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
sais pascomment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil
Hello,
peux tu préciser un peu?
Tu veux:
- Créer une base: pas ouvrir une existante, mais la créer?
Tu veux donc ensuite créer tes tables, les index, etc?
Est ce bien cela?
Car en général, on créé la base avec Access, et le programme VB
se contente de la manipuler.
A moins que tu veuilles faire un programme dont le but est
justement de CREER des bases de données ?
--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Non c'est exactement cela, je veux savoir comment créer une base de
dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
des informations.
"Jean-Marc" a écrit dans le message de
440083c8$0$3803$
> "Julien" a écrit dans le message de
> news:
>> Bonjour, je suis débutant sur le développement sous visual basic,
> général
>> je développe sous VBA...
>> J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
> sais pas
>> comment créer une base de données !!
>> Si quelqun pouvais m'aider un petit peu ça serai gentil
>
> Hello,
>
> peux tu préciser un peu?
>
> Tu veux:
> - Créer une base: pas ouvrir une existante, mais la créer?
>
> Tu veux donc ensuite créer tes tables, les index, etc?
>
> Est ce bien cela?
>
> Car en général, on créé la base avec Access, et le programme VB
> se contente de la manipuler.
>
> A moins que tu veuilles faire un programme dont le but est
> justement de CREER des bases de données ?
>
> --
> Jean-marc
> Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
> "There are only 10 kind of people
> those who understand binary and those who don't."
> mailto: remove '_no_spam_' ;
>
Non c'est exactement cela, je veux savoir comment créer une base de
dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
des informations.
"Jean-Marc" <NO_SPAM_jean_marc_n2@yahoo.fr> a écrit dans le message de
440083c8$0$3803$ba620e4c@news.skynet.be...
> "Julien" <tazou@hotmail.com> a écrit dans le message de
> news:eFDnv0FOGHA.420@tk2msftngp13.phx.gbl...
>> Bonjour, je suis débutant sur le développement sous visual basic,
> général
>> je développe sous VBA...
>> J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
> sais pas
>> comment créer une base de données !!
>> Si quelqun pouvais m'aider un petit peu ça serai gentil
>
> Hello,
>
> peux tu préciser un peu?
>
> Tu veux:
> - Créer une base: pas ouvrir une existante, mais la créer?
>
> Tu veux donc ensuite créer tes tables, les index, etc?
>
> Est ce bien cela?
>
> Car en général, on créé la base avec Access, et le programme VB
> se contente de la manipuler.
>
> A moins que tu veuilles faire un programme dont le but est
> justement de CREER des bases de données ?
>
> --
> Jean-marc
> Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
> "There are only 10 kind of people
> those who understand binary and those who don't."
> mailto: remove '_no_spam_' ; _no_spam_jean_marc_n2@yahoo.fr
>
Non c'est exactement cela, je veux savoir comment créer une base de
dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
des informations.
"Jean-Marc" a écrit dans le message de
440083c8$0$3803$
> "Julien" a écrit dans le message de
> news:
>> Bonjour, je suis débutant sur le développement sous visual basic,
> général
>> je développe sous VBA...
>> J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
> sais pas
>> comment créer une base de données !!
>> Si quelqun pouvais m'aider un petit peu ça serai gentil
>
> Hello,
>
> peux tu préciser un peu?
>
> Tu veux:
> - Créer une base: pas ouvrir une existante, mais la créer?
>
> Tu veux donc ensuite créer tes tables, les index, etc?
>
> Est ce bien cela?
>
> Car en général, on créé la base avec Access, et le programme VB
> se contente de la manipuler.
>
> A moins que tu veuilles faire un programme dont le but est
> justement de CREER des bases de données ?
>
> --
> Jean-marc
> Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
> "There are only 10 kind of people
> those who understand binary and those who don't."
> mailto: remove '_no_spam_' ;
>
Non c'est exactement cela, je veux savoir comment créer une base de données dans
laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou supprimer des
informations.
Non c'est exactement cela, je veux savoir comment créer une base de données dans
laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou supprimer des
informations.
Non c'est exactement cela, je veux savoir comment créer une base de données dans
laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou supprimer des
informations.
Bonjour à Julien qui nous a écrit :Non c'est exactement cela, je veux savoir comment créer une base de
données dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.
Bonjour à Julien qui nous a écrit :
Non c'est exactement cela, je veux savoir comment créer une base de
données dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.
Bonjour à Julien qui nous a écrit :Non c'est exactement cela, je veux savoir comment créer une base de
données dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.
Salutatoi Geo,
Tu as donc déclaré :Bonjour à Julien qui nous a écrit :Non c'est exactement cela, je veux savoir comment créer une base de
données dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout lire et toute écrire
chaque fois. Il est donc recommandé pour les petites bases.
Cependant, lorsque le fichier est stucturé (champs de longueurs fixe) et que le nombre
de données est important, il est recommandé d'utiliser un fichier à accès direct dans
lequel on ne manipule qu'une fiche à la fois.
Salutatoi Geo,
Tu as donc déclaré :
Bonjour à Julien qui nous a écrit :
Non c'est exactement cela, je veux savoir comment créer une base de
données dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout lire et toute écrire
chaque fois. Il est donc recommandé pour les petites bases.
Cependant, lorsque le fichier est stucturé (champs de longueurs fixe) et que le nombre
de données est important, il est recommandé d'utiliser un fichier à accès direct dans
lequel on ne manipule qu'une fiche à la fois.
Salutatoi Geo,
Tu as donc déclaré :Bonjour à Julien qui nous a écrit :Non c'est exactement cela, je veux savoir comment créer une base de
données dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout lire et toute écrire
chaque fois. Il est donc recommandé pour les petites bases.
Cependant, lorsque le fichier est stucturé (champs de longueurs fixe) et que le nombre
de données est important, il est recommandé d'utiliser un fichier à accès direct dans
lequel on ne manipule qu'une fiche à la fois.
Salutatoi Geo,
Tu as donc déclaré :
> Bonjour à Julien qui nous a écrit :
>
>> Non c'est exactement cela, je veux savoir comment créer une base
>> données dans laquelle VB vas stocker les données que je vais y
>> Mon programme se basera sur cette base de données pour modifier ou
>> supprimer des informations.
>
> Tu peux faire un simple fichier texte dont tu lis et écris les
> comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout
toute écrire chaque fois. Il est donc recommandé pour les petites
Cependant, lorsque le fichier est stucturé (champs de longueurs fixe)
le nombre de données est important, il est recommandé d'utiliser un
à accès direct dans lequel on ne manipule qu'une fiche à la fois.
Salutatoi Geo,
Tu as donc déclaré :
> Bonjour à Julien qui nous a écrit :
>
>> Non c'est exactement cela, je veux savoir comment créer une base
>> données dans laquelle VB vas stocker les données que je vais y
>> Mon programme se basera sur cette base de données pour modifier ou
>> supprimer des informations.
>
> Tu peux faire un simple fichier texte dont tu lis et écris les
> comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout
toute écrire chaque fois. Il est donc recommandé pour les petites
Cependant, lorsque le fichier est stucturé (champs de longueurs fixe)
le nombre de données est important, il est recommandé d'utiliser un
à accès direct dans lequel on ne manipule qu'une fiche à la fois.
Salutatoi Geo,
Tu as donc déclaré :
> Bonjour à Julien qui nous a écrit :
>
>> Non c'est exactement cela, je veux savoir comment créer une base
>> données dans laquelle VB vas stocker les données que je vais y
>> Mon programme se basera sur cette base de données pour modifier ou
>> supprimer des informations.
>
> Tu peux faire un simple fichier texte dont tu lis et écris les
> comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout
toute écrire chaque fois. Il est donc recommandé pour les petites
Cependant, lorsque le fichier est stucturé (champs de longueurs fixe)
le nombre de données est important, il est recommandé d'utiliser un
à accès direct dans lequel on ne manipule qu'une fiche à la fois.
ne pas oublier non plus que tout est question d'échelle.
Exemples:
* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative
* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)
* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases
<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>
* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!
Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?
Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?
On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace.
Evidemment, c'est souvent plus pour le sport qu'autre chose: on se
retrouve à implémenter un subset de SQL, à réinventer les Index, etc.
Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".
ne pas oublier non plus que tout est question d'échelle.
Exemples:
* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative
* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)
* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases
<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>
* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!
Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?
Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?
On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace.
Evidemment, c'est souvent plus pour le sport qu'autre chose: on se
retrouve à implémenter un subset de SQL, à réinventer les Index, etc.
Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".
ne pas oublier non plus que tout est question d'échelle.
Exemples:
* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative
* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)
* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases
<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>
* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!
Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?
Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?
On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace.
Evidemment, c'est souvent plus pour le sport qu'autre chose: on se
retrouve à implémenter un subset de SQL, à réinventer les Index, etc.
Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".
Bonjour à Aski qui nous a écrit :Salutatoi Geo,
Tu as donc déclaré :Bonjour à Julien qui nous a écrit :Non c'est exactement cela, je veux savoir comment créer une base
de données dans laquelle VB vas stocker les données que je vais y
saisir Mon programme se basera sur cette base de données pour
modifier ou supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les
lignes comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout
lire et toute écrire chaque fois. Il est donc recommandé pour les
petites bases.
Et on peut le modifier avec le bloc-note ou tout traitement de texte
:-)Cependant, lorsque le fichier est stucturé (champs de longueurs
fixe) et que le nombre de données est important, il est recommandé
d'utiliser un fichier à accès direct dans lequel on ne manipule
qu'une fiche à la fois.
Chiche qu'on peut accéder en direct sur un fichier texte créé en vb.
Suffit de faire des lignes de longueur fixe.
Quand on débute en VB vaut mieux faire des trucs simples.
Bonjour à Aski qui nous a écrit :
Salutatoi Geo,
Tu as donc déclaré :
Bonjour à Julien qui nous a écrit :
Non c'est exactement cela, je veux savoir comment créer une base
de données dans laquelle VB vas stocker les données que je vais y
saisir Mon programme se basera sur cette base de données pour
modifier ou supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les
lignes comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout
lire et toute écrire chaque fois. Il est donc recommandé pour les
petites bases.
Et on peut le modifier avec le bloc-note ou tout traitement de texte
:-)
Cependant, lorsque le fichier est stucturé (champs de longueurs
fixe) et que le nombre de données est important, il est recommandé
d'utiliser un fichier à accès direct dans lequel on ne manipule
qu'une fiche à la fois.
Chiche qu'on peut accéder en direct sur un fichier texte créé en vb.
Suffit de faire des lignes de longueur fixe.
Quand on débute en VB vaut mieux faire des trucs simples.
Bonjour à Aski qui nous a écrit :Salutatoi Geo,
Tu as donc déclaré :Bonjour à Julien qui nous a écrit :Non c'est exactement cela, je veux savoir comment créer une base
de données dans laquelle VB vas stocker les données que je vais y
saisir Mon programme se basera sur cette base de données pour
modifier ou supprimer des informations.
Tu peux faire un simple fichier texte dont tu lis et écris les
lignes comme tu veux.
Le fichier texte est le plus simple à manipuler, mais il faut tout
lire et toute écrire chaque fois. Il est donc recommandé pour les
petites bases.
Et on peut le modifier avec le bloc-note ou tout traitement de texte
:-)Cependant, lorsque le fichier est stucturé (champs de longueurs
fixe) et que le nombre de données est important, il est recommandé
d'utiliser un fichier à accès direct dans lequel on ne manipule
qu'une fiche à la fois.
Chiche qu'on peut accéder en direct sur un fichier texte créé en vb.
Suffit de faire des lignes de longueur fixe.
Quand on débute en VB vaut mieux faire des trucs simples.
Salutatoi Jean-Marc,
Tu as donc déclaré :ne pas oublier non plus que tout est question d'échelle.
Exemples:
* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative
* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)
* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases
<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>
* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!
Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?
Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?
On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace.
Evidemment, c'est souvent plus pour le sport qu'autre chose: on se
retrouve à implémenter un subset de SQL, à réinventer les Index, etc.
Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".
On parle bien de fichiers à gérer depuis VB.
Gérer un fichier ADR est quand-même plus simple que de gérer un fichier
Access depuis VB.
Salutatoi Jean-Marc,
Tu as donc déclaré :
ne pas oublier non plus que tout est question d'échelle.
Exemples:
* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative
* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)
* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases
<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>
* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!
Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?
Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?
On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace.
Evidemment, c'est souvent plus pour le sport qu'autre chose: on se
retrouve à implémenter un subset de SQL, à réinventer les Index, etc.
Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".
On parle bien de fichiers à gérer depuis VB.
Gérer un fichier ADR est quand-même plus simple que de gérer un fichier
Access depuis VB.
Salutatoi Jean-Marc,
Tu as donc déclaré :ne pas oublier non plus que tout est question d'échelle.
Exemples:
* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative
* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)
* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases
<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>
* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!
Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?
Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?
On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace.
Evidemment, c'est souvent plus pour le sport qu'autre chose: on se
retrouve à implémenter un subset de SQL, à réinventer les Index, etc.
Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".
On parle bien de fichiers à gérer depuis VB.
Gérer un fichier ADR est quand-même plus simple que de gérer un fichier
Access depuis VB.