Base de données relationelle ou simple table

Le
Yann
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
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pierre CFI
Le #6410101
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"
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
Le #6410301
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
Richard_35
Le #6411281
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" 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



Publicité
Poster une réponse
Anonyme