Je cherche à construire une base de données d'informations sur des
utilisateurs.
- J'ai de nombreux utilisateurs (et cette liste est amenée à progresser)
- j'ai de plus en plus d'information sur eux (nom prénom .. mais aussi des
information de type consomme le produit A, répond bleu à telle question ...
aime tel artiste de musique... (info qui arrivent avec un nouvel utilisateur
ou suite à une enquète sur les utilisateurs existants)
Mon problème est que je ne sais sous quel forme stocker ces données.
j'ai en effet de nombreux individus et pour chacun d'eux certaines infos
sont disponibles et d'autres pas.
Ma question est donc : quelle structure adopter ?
Système 1
- une table unique avec 40 - 50 champs ..
ex
ID-----Nom-----musique
250---"Pierre"---"REM"
251---"Paul"-----"Noir_desir"
252---"Jaques"---
Système 2
- une table principale comportant ma clé principale et d'autres tables sur
des sujet donnés ex thème musique qui reprennent la clé principale
table principale
ID-----Nom
250---"Pierre"
251---"Paul"
252---"Jaques"
Table musique
ID-----musique
250---"REM"
251---"Noir_desir"
252 n'y est pas car pas d'info musique
Le système 1 est plus simple a construire mais lourd à exploiter
le système 2 est plus élégant mais quand je vais rajouter un enregistrement
je vais devoir faire pas mal de manips .. le rajouter à la table principale
puis aux tables secondaire... et pour les mises à jours ...
et tt ça sachant que je ne programme pas :-(
Si vous avez des conseils je suis super intéressé :-)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pierre CFI
bonjour un conseil simple, potasse un tout petit peu, le principe des bases de données çà me semble étre l'évidence premiére :o)) -- Pierre CFI
"Yann" a écrit dans le message de news:
Bonjour
Je cherche à construire une base de données d'informations sur des utilisateurs. - J'ai de nombreux utilisateurs (et cette liste est amenée à progresser) - j'ai de plus en plus d'information sur eux (nom prénom .. mais aussi des information de type consomme le produit A, répond bleu à telle question ... aime tel artiste de musique... (info qui arrivent avec un nouvel utilisateur ou suite à une enquète sur les utilisateurs existants)
Mon problème est que je ne sais sous quel forme stocker ces données. j'ai en effet de nombreux individus et pour chacun d'eux certaines infos sont disponibles et d'autres pas.
Ma question est donc : quelle structure adopter ?
Système 1 - une table unique avec 40 - 50 champs .. ex ID-----Nom-----musique 250---"Pierre"---"REM" 251---"Paul"-----"Noir_desir" 252---"Jaques"---
Système 2 - une table principale comportant ma clé principale et d'autres tables sur des sujet donnés ex thème musique qui reprennent la clé principale
table principale ID-----Nom 250---"Pierre" 251---"Paul" 252---"Jaques"
Table musique ID-----musique 250---"REM" 251---"Noir_desir"
252 n'y est pas car pas d'info musique
Le système 1 est plus simple a construire mais lourd à exploiter le système 2 est plus élégant mais quand je vais rajouter un enregistrement je vais devoir faire pas mal de manips .. le rajouter à la table principale puis aux tables secondaire... et pour les mises à jours ...
et tt ça sachant que je ne programme pas :-(
Si vous avez des conseils je suis super intéressé :-)
Bonne soirée et bon WE
yann
bonjour
un conseil simple, potasse un tout petit peu, le principe des bases de
données
çà me semble étre l'évidence premiére :o))
--
Pierre CFI
"Yann" <Yann@discussions.microsoft.com> a écrit dans le message de news:
831AA8B6-F89A-4E7F-89DB-2AEC5601F68D@microsoft.com...
Bonjour
Je cherche à construire une base de données d'informations sur des
utilisateurs.
- J'ai de nombreux utilisateurs (et cette liste est amenée à progresser)
- j'ai de plus en plus d'information sur eux (nom prénom .. mais aussi des
information de type consomme le produit A, répond bleu à telle question
...
aime tel artiste de musique... (info qui arrivent avec un nouvel
utilisateur
ou suite à une enquète sur les utilisateurs existants)
Mon problème est que je ne sais sous quel forme stocker ces données.
j'ai en effet de nombreux individus et pour chacun d'eux certaines infos
sont disponibles et d'autres pas.
Ma question est donc : quelle structure adopter ?
Système 1
- une table unique avec 40 - 50 champs ..
ex
ID-----Nom-----musique
250---"Pierre"---"REM"
251---"Paul"-----"Noir_desir"
252---"Jaques"---
Système 2
- une table principale comportant ma clé principale et d'autres tables sur
des sujet donnés ex thème musique qui reprennent la clé principale
table principale
ID-----Nom
250---"Pierre"
251---"Paul"
252---"Jaques"
Table musique
ID-----musique
250---"REM"
251---"Noir_desir"
252 n'y est pas car pas d'info musique
Le système 1 est plus simple a construire mais lourd à exploiter
le système 2 est plus élégant mais quand je vais rajouter un
enregistrement
je vais devoir faire pas mal de manips .. le rajouter à la table
principale
puis aux tables secondaire... et pour les mises à jours ...
et tt ça sachant que je ne programme pas :-(
Si vous avez des conseils je suis super intéressé :-)
bonjour un conseil simple, potasse un tout petit peu, le principe des bases de données çà me semble étre l'évidence premiére :o)) -- Pierre CFI
"Yann" a écrit dans le message de news:
Bonjour
Je cherche à construire une base de données d'informations sur des utilisateurs. - J'ai de nombreux utilisateurs (et cette liste est amenée à progresser) - j'ai de plus en plus d'information sur eux (nom prénom .. mais aussi des information de type consomme le produit A, répond bleu à telle question ... aime tel artiste de musique... (info qui arrivent avec un nouvel utilisateur ou suite à une enquète sur les utilisateurs existants)
Mon problème est que je ne sais sous quel forme stocker ces données. j'ai en effet de nombreux individus et pour chacun d'eux certaines infos sont disponibles et d'autres pas.
Ma question est donc : quelle structure adopter ?
Système 1 - une table unique avec 40 - 50 champs .. ex ID-----Nom-----musique 250---"Pierre"---"REM" 251---"Paul"-----"Noir_desir" 252---"Jaques"---
Système 2 - une table principale comportant ma clé principale et d'autres tables sur des sujet donnés ex thème musique qui reprennent la clé principale
table principale ID-----Nom 250---"Pierre" 251---"Paul" 252---"Jaques"
Table musique ID-----musique 250---"REM" 251---"Noir_desir"
252 n'y est pas car pas d'info musique
Le système 1 est plus simple a construire mais lourd à exploiter le système 2 est plus élégant mais quand je vais rajouter un enregistrement je vais devoir faire pas mal de manips .. le rajouter à la table principale puis aux tables secondaire... et pour les mises à jours ...
et tt ça sachant que je ne programme pas :-(
Si vous avez des conseils je suis super intéressé :-)
Bonne soirée et bon WE
yann
Christian CASTEX
Bonjour,
il n'y a pas a savoir programmer pour faire ce truc
Pour la saisie, il te faut un formulaire principal qui te permette de choisir ton utilisateur, lié à un sous formulaire qui t'affiche ce que tu as déjà dans tes tables sur cet utilisateur et qui te permette de saisir une autre information.
Pour les affichages, tu utilise de simples requêtes.
Mais Access, c'est surtout savoir utiliser des requêtes et des formulaires. Alors achête un bon bouquin de type "pour les nuls" et ça ira mieux.
Cordialement
Christian
Bonjour,
il n'y a pas a savoir programmer pour faire ce truc
Pour la saisie, il te faut un formulaire principal qui te permette de
choisir ton utilisateur, lié à un sous formulaire qui t'affiche ce que tu as
déjà dans tes tables sur cet utilisateur et qui te permette de saisir une
autre information.
Pour les affichages, tu utilise de simples requêtes.
Mais Access, c'est surtout savoir utiliser des requêtes et des formulaires.
Alors achête un bon bouquin de type "pour les nuls" et ça ira mieux.
il n'y a pas a savoir programmer pour faire ce truc
Pour la saisie, il te faut un formulaire principal qui te permette de choisir ton utilisateur, lié à un sous formulaire qui t'affiche ce que tu as déjà dans tes tables sur cet utilisateur et qui te permette de saisir une autre information.
Pour les affichages, tu utilise de simples requêtes.
Mais Access, c'est surtout savoir utiliser des requêtes et des formulaires. Alors achête un bon bouquin de type "pour les nuls" et ça ira mieux.
Cordialement
Christian
Richard_35
Bonjour Christian,
Excuses-moi, mais je ne suis pas d'accord avec "Mais Access, c'est surtout savoir utiliser des requêtes et des formulaires".
Avant tout, comme le dit Pierre, il faut avoir des notions d'analyse pure ; donc, savoir "se battre" avec les données. En gros, pour commencer, il faut : - maîtriser le principe des clés primaires (identifiant unique d'une table). - maîtriser le principe des relations 1 pour N, 1 pour 1 et N pour N. Sans maîtrise (plus ou moins) de ces sujets, tu pourras être un maître es-Access en requêtes, formulaires, macro, VBA, etc..., tes applications ne seront jamais au point ; avec, par exemple, une maîtrise de VBA, tu résoudras tes erreurs d'analyse par du code, ce qui alourdira considérablement l'application, avec des "verrues" partout... et qui, à terme, deviendra in-maintenable. Tu remarqueras que, avec une analyse bien faite, les requêtes, formulaires, et, éventuellement code VBA "coulent" toutes seules... avec, à peu près, toujours les mêmes "briques" à développer. D'ailleurs, avec une analyse bien faite, souvent, tu peux te passer de code VBA en utilisant les assistants (ce que je fais, car je ne connais pas VBA).
En résumé, Access n'est qu'un outil pour travailler avec des données, mais pas une fin en soi.
A bientôt, Richard.
"Christian CASTEX" a écrit dans le message de news:
Bonjour,
il n'y a pas a savoir programmer pour faire ce truc
Pour la saisie, il te faut un formulaire principal qui te permette de choisir ton utilisateur, lié à un sous formulaire qui t'affiche ce que tu as déjà dans tes tables sur cet utilisateur et qui te permette de saisir une autre information.
Pour les affichages, tu utilise de simples requêtes.
Mais Access, c'est surtout savoir utiliser des requêtes et des formulaires. Alors achête un bon bouquin de type "pour les nuls" et ça ira mieux.
Cordialement
Christian
Bonjour Christian,
Excuses-moi, mais je ne suis pas d'accord avec "Mais Access, c'est
surtout savoir utiliser des requêtes et des formulaires".
Avant tout, comme le dit Pierre, il faut avoir des notions d'analyse
pure ; donc, savoir "se battre" avec les données.
En gros, pour commencer, il faut :
- maîtriser le principe des clés primaires (identifiant unique d'une
table).
- maîtriser le principe des relations 1 pour N, 1 pour 1 et N pour
N.
Sans maîtrise (plus ou moins) de ces sujets, tu pourras être un maître
es-Access en requêtes, formulaires, macro, VBA, etc..., tes applications ne
seront jamais au point ; avec, par exemple, une maîtrise de VBA, tu
résoudras tes erreurs d'analyse par du code, ce qui alourdira
considérablement l'application, avec des "verrues" partout... et qui, à
terme, deviendra in-maintenable.
Tu remarqueras que, avec une analyse bien faite, les requêtes,
formulaires, et, éventuellement code VBA "coulent" toutes seules... avec, à
peu près, toujours les mêmes "briques" à développer. D'ailleurs, avec une
analyse bien faite, souvent, tu peux te passer de code VBA en utilisant les
assistants (ce que je fais, car je ne connais pas VBA).
En résumé, Access n'est qu'un outil pour travailler avec des données,
mais pas une fin en soi.
A bientôt,
Richard.
"Christian CASTEX" <ChristianCASTEX@discussions.microsoft.com> a écrit dans
le message de news: 2E524A76-D592-4298-922E-CDE9EB7795EA@microsoft.com...
Bonjour,
il n'y a pas a savoir programmer pour faire ce truc
Pour la saisie, il te faut un formulaire principal qui te permette de
choisir ton utilisateur, lié à un sous formulaire qui t'affiche ce que tu
as
déjà dans tes tables sur cet utilisateur et qui te permette de saisir une
autre information.
Pour les affichages, tu utilise de simples requêtes.
Mais Access, c'est surtout savoir utiliser des requêtes et des
formulaires.
Alors achête un bon bouquin de type "pour les nuls" et ça ira mieux.
Excuses-moi, mais je ne suis pas d'accord avec "Mais Access, c'est surtout savoir utiliser des requêtes et des formulaires".
Avant tout, comme le dit Pierre, il faut avoir des notions d'analyse pure ; donc, savoir "se battre" avec les données. En gros, pour commencer, il faut : - maîtriser le principe des clés primaires (identifiant unique d'une table). - maîtriser le principe des relations 1 pour N, 1 pour 1 et N pour N. Sans maîtrise (plus ou moins) de ces sujets, tu pourras être un maître es-Access en requêtes, formulaires, macro, VBA, etc..., tes applications ne seront jamais au point ; avec, par exemple, une maîtrise de VBA, tu résoudras tes erreurs d'analyse par du code, ce qui alourdira considérablement l'application, avec des "verrues" partout... et qui, à terme, deviendra in-maintenable. Tu remarqueras que, avec une analyse bien faite, les requêtes, formulaires, et, éventuellement code VBA "coulent" toutes seules... avec, à peu près, toujours les mêmes "briques" à développer. D'ailleurs, avec une analyse bien faite, souvent, tu peux te passer de code VBA en utilisant les assistants (ce que je fais, car je ne connais pas VBA).
En résumé, Access n'est qu'un outil pour travailler avec des données, mais pas une fin en soi.
A bientôt, Richard.
"Christian CASTEX" a écrit dans le message de news:
Bonjour,
il n'y a pas a savoir programmer pour faire ce truc
Pour la saisie, il te faut un formulaire principal qui te permette de choisir ton utilisateur, lié à un sous formulaire qui t'affiche ce que tu as déjà dans tes tables sur cet utilisateur et qui te permette de saisir une autre information.
Pour les affichages, tu utilise de simples requêtes.
Mais Access, c'est surtout savoir utiliser des requêtes et des formulaires. Alors achête un bon bouquin de type "pour les nuls" et ça ira mieux.
