probléme choix de table

29 déc. 2005, 18:21

Bonjour,
J'ai un petit souci, je ne sait pas quelle solution choisir pour la creation d'une table dans mon projet.
Pour mon projet, chaqu'un de mes membres a accés a 6 zones, et chaque des zones ont 6 choix identique (choix1,choix2,...) (les choix sont des options independante en elle meme ex:choix1=couleur, choix2=typo).
Alors mon choix ce portais plutot sur une solution:
créer une tablede ce style:
id | id_zone | membre | choix1 | choix2 | choix3 | choix4 | choix5 |choix6

Avec cette solution, lors de son inscription le membre sera inséré 6 fois dans la table (une fois par zone), avec ces choix personalisable pour chaque zone.
Mais il y a d'autre possibilité ex:

id | membre | choix1_zone1 | choix2_zone1 | ... | choix6_zone1 | choix1_zone2 | .... (comme sa jusqu'a choix6_zone6)

Alors avec cette solution,chaque membre ne sera inséré qu'une seule fois dans la table, mais il y a bcp de champ.
Alors j'ai essayé les 2, et j'ai regardé au niveau de la taille (les donnés pour chaque champ sont identique):
resultat type1:
Données 144 Octets
Index 2 048 Octets
Total 2 192 Octets
Enregistrements 6
Longueur enr. ø 24
Taille enr. ø 365 Octets

resultat type2:
Données 60 Octets
Index 2 048 Octets
Total 2 108 Octets
Enregistrements 1
Longueur enr. ø 60
Taille enr. ø 2 108 Octets

D'aprés le resultat, la 2éme solution semble prendre moins de place.
Il est egalement possible de faire une table pour chaque zone.
Donc la je ne sait pas trop quelle solution choisir, si certain d'entre vous pouvez me conseillez afin de choisir la meilleur solution (afin que se soit le mieux optimisé pour la place, mais egalement pratique), et si vous voyé une autre solution pour mon projet je suis ouvet a tout

Je vous remercie d'avance

30 déc. 2005, 00:40

Tu pourrais séparer en deux entités: une entité membres et une entité zones, ce qui donnerait deux tables :
Tu n'auras coté zones qu'une petite table avec une ligne par zone comprenant une clé primaire et une description par exemple.

Si j'ai correctement compris ton problème, un membre peut accéder à 0 à n zones et une zone peut recevoir 0 à n membres : tu dois donc avoir une relation entre les deux qui se matérialisera par une table qui aura une clé primaire composite constituée des deux clés étrangères reprises selon les clés primaires de la table membre d'un coté et de la table zone de l'autre.

Ce qui donne le schéma (très sommaire) suivant:

Code : Tout sélectionner

+---------------+           +------------------+           +-------------------+
|    membre     |           |      visite      |           |        zones      |
+---------------+           +------------------+           +-------------------+
| mem_id     PK |-----------| mem_id     FK  PK|-----------| zon_id         PK |
| mem_pseudo    |           | zon_id     FK  PK|           | zon_desc          |
+---------------+           +------------------+           +-------------------+

Est-ce que ça te parle ou ça a l'air terriblement compliqué ?

31 déc. 2005, 16:00

Bonjour,
Merci d'avoir repondu

Alors pour te repondre, je dirai que sa ne me parle pas beaucoup

L'autre idée etait de tout mettre dans une seul table, mais la il y aura enormement de champ, et le rendu pourrait peut etre rendre un peu "fouilli".
ex:

preference:
id | pseudo | donné1 zone1 | donné2 zone1 | donné3 zone1 ......

Avec cette méthode, dans la table, il y aura 6 champ pour 1 zone, donc pour 6 zone, sa ferait 36 champ... je suis pas sur que cela soit vraiment la meilleur methode non plus :s

Donc j'espere avoir reussi a expliqué correctement, et que vous pourrez m'aidez a y voir plus clair.
Je vous remercie d'avance

P.S: il est possible que je n'est pas posté dans le topic approprié, peut etre que ce post aurait plus sa place dans la rubrique "modelisation", si c'est le cas, veuillez m'excusez"

02 janv. 2006, 20:04

Au lieu de reposer le problème ailleurs, explique donc ce que tu n'as pas compris de mes explications précédentes.

02 janv. 2006, 20:25

Bonsoir,
Désolé pour le doublon

Alors dans mon projet,en fait, chaque membre aura directement accés au 6 zone (il s'agit de section de pages), donc je ne sait pas si sa peut se matérialisé par "un membre peut avoir accés de 0 a n zones" (vus qu'il y sera autoamtiquement), idem pour les zones, qui elles afficheront automatiquements les preferences du membre.
J'ai essayé de précisé plus dans mon precedent post :s
Je vous remercie d'avance

02 janv. 2006, 22:07

Combien aura tu de zones au total (pas par membre, ça j'ai compris que c'est 6 maxi, je dis bien au total)

03 janv. 2006, 16:23

Il y a maximum 6 zone.
(j'ai cherché une comparaison pour indiquez quelque chose de plus concret, alors on peut comparé chaqu'une de mes zones a un jeu, et les donné de ces zones, on peut les comparés a un meilleur score, et autre donné de jeu (difficulté...), donc dans ce cas, chaqu'un des membres aurait des stats sur chaque jeux ( si pas encore de parti joué, meilleur score=0, difficulté=normal...), sinon les donné sont mise a jours lors de la partie du membre, avec cette comparaison, sa donne 6 jeu ou chaque membre va joué, avec chaqu'un des jeux, 6 donnée propre (meilleur score, difficulté...)
C'est peu etre plus explicite avec une comparaison comme sa

03 janv. 2006, 16:30

Si tu reprends le schéma que j'ai mis plus haut, tu pourrais avoir trois tables et avoir dans la relation (table intermédiaire) une colonne "donnée", ce qui te dispense de multiplieer les lignes dans la table membre ou la table zone : si tu as une doénnée pour une zone pour un membre, tu ajoutes une ligne dans la table intermédiaire, mais rien dans les autres.

Est-ce que tu visualises l'idée ou pas ?

Note : j'ai ajouté un post-it au forum pointant vers un tuto sur la modélisation, tu devrais y jeter un coup d'oeil, tu y découvriras une méthode de modélisation particulièrement efficace et des règles techniques fondamentales importantes.

probléme choix de table

Qui est en ligne