Discussion :

[Michaeljackfan]

Bonjour,

j'ai comme projet de faire un site de rencontre, ce qui signifie qu'il me faudra recueillir de nombreuses informations (taille, âge, sexe, pseudo, mot de passe, location, description, régime alimentaire etc.)

J'aimerai savoir s'il est préférable de faire une seule table avec une centaine de champs; ou bien plusieurs petites contenant chacune une dizaine d'informations.


J'ai vu sur internet qu'il vallait mieux séparer en plusieurs tables, mais c'était lorsque le nombre d'entrées devenait trop grand. Je n'ai rien trouvé en ce qui concerne un nombre de champs important.

Merci à qui me répondra

[CinePhil]

Question déjà posée il n'y a pas longtemps. Il y a un outil de recherche.

Dans ton cas, tu vas avoir probablement beaucoup de données non renseignées par les personnes, ce qui pourrait engendrer beaucoup de NULL dans la table des personnes.

De plus, tu peux vouloir ajouter des informations plus tard pour affiner les recherches.

Le mieux est probablement que tu utilises une table de critères associée à la table des personnes.

Personne -0,n----Répondre(valeur)----0,n- Critere

Il te faut déterminer quels sont les critères obligatoires pour toutes les personnes afin de constituer le table des personnes. Tout le reste, tu le passes en critères.

t_e_personne_prs (prs_id, prs_nom, prs_prenom, prs_pseudo, prs_mot_passe, prs_sexe, prs_date_naissance, prs_id_commune...)
t_e_critere_crt (crt_id, crt_libelle)
t_j_prs_repondre_crt_prc (prc_id_personne, prc_id_critere, prc_valeur)

[Michaeljackfan]

Je n'y avais pas pensé, c'est effectivement c'est une très bonne idée !

Merci beaucoup


PS: J'avais fait une recherche sur le forum. Apparemment je n'ai pas utilisé les bons mots-clé.

[Michaeljackfan]

Bonjour,

J'aurai une autre question concernant le schéma de mon site.

Certaines photos doivent être privées et accessibles seulement par les "amis" du membre. Alors je pensais mettre les photos dans un répertoire avant celui du site à proprement parler:

private <- répertoire contenant les fichiers des membres
www <- répertoire qui contient "index.php" et vers lequel nous dirige le monsite.com


Ensuite une fonction php se charge d'aller lire le fichier demandé. Pour savoir si on a le droit d'accéder à l'image, il ferai appel à mySQL, ouvrirait une table contenant des id_file, accompagnés du nom du fichier et du groupe qui a le droit de les ouvrir. Il vérifierai avec la session si le membre fait partie de ce groupe.


Est-ce une méthode sûr et convenable ?

[Vil'Coyote]

ça dépend. si ton utilisateur fait partie de plusieurs groupe mais qu'il ne veut pas donner l'accès à tous les groupes dans ton cas c'est pas jouable?

[Michaeljackfan]

Et bien en fait ça se présente comme ça (ou à peu près, je ne suis pas encore sûr de la meilleure méthode)


table group:
id, id_member, name

id = id du groupe
id_member = id du membre qui l'a créé
name = nom du groupe


table: file
id, id_member, file_path, name, id_group

id = id du fichier
id_member = id du membre qui l'a uploadé
file_path = chemin du fichier (enfin son nom, car son chemin est connu avec l'id du membre)
name = nom du fichier tel qu'il sera affiché (car dans les dossier ce sera 1.jpg, 2.txt etc. Mais les membres pourront choisir le nom "affiché" de leur fichier).
id_group = groupe ayant le droit d'accéder au fichier


table: group_membership
id, id_member, id_group

id = id du "group_membership"
id_member = id du membre qui fait partie de ce groupe
id_group = id du groupe dont il fait partie


Chaque fois qu'un utilisateur crée un groupe, ça fait une entrée de plus dans "group" avec une id unique. Et pour chaque utilisateur qu'il ajoute à ce groupe, ça ajoute une entrée à "group_membership".
ça fait beaucoup d'entrées: une par groupe et par membre qui y est inscrit, mais ça autorise beaucoup de choses.

Donc étape 1: on regarde avec l'id du fichier de quel groupe il fait partie.
étape 2: on regarde dans group_membership si notre membre fait partie de ce groupe.

[Michaeljackfan]

J'ai utilisé "Open ModelSphere" et j'ai fait quelques modifications.

Et pourquoi pas des noms en français d'ailleurs ?

Parce que les noms français comportent des accents, des "ç" etc.
Bien sûr on peut les enlever, mais je préfère écrire correctement un nom anglais.


Pour info: les "label" sont les noms affichés choisis par le membre
Tandis que "name" est un nom dont je me sert pour recueillir l'information.
Par exemple: if($requete['research'][0]=='love'); "research" est contenu dans "name", donc c'est un mot précis que je mets dans le champ.


voici le nouveau model:

[CinePhil]

Ton schéma a des cardinalités comme sur un MCD mais il y manque les "patates" des associations pour être un MCD. Par contre il mentionne les clés étrangères comme dans un MLD mais il manque les flèches pour que ce soit un MLD classique !

On va faire avec et je lis le "MCLD"

1) Accès à un fichier
Je suppose que l'association entre file et members (pourquoi file au singulier et members au pluriel ? Normalement on nomme les entités au singulier) signifie qu'un file appartient à un seul members, ce qui veut dire que le sens des cardinalités est celui des multiplicités du diagramme de classes UML ; décidément y a du mélange !

Un file_access ne concerne qu'un fichier, ce qui semble logique.

Un file access peut concerner plusieurs group_access et un group_access peut avoir plusieurs file_access. Les cardinalités 0,n - 0,n entraîneront la création d'une table associative.

Un group_access n'est associé qu'à un seul member. C'est le créateur du group_access ?

Une fois encore, il manque les verbes donnant du sens aux associations pour mieux comprendre le schéma.

Où sont modélisés les groupes et leur composition ?

2) Contacts
Je suppose que la table members est la même que la précédente. Pourquoi ne pas avoir fait un seul schéma ?

D'après la cardinalité 1,1, un contact n'appartient qu'à un member. Quelle est la clé étrangère qui matérialise cette dépendance ?

Je suppose que id_sender et id_receiver font référence chacune à un member. Pourtant, il n'y a qu'une seule association entre les contacts et les members. Il en manque une !

3) Informations
Revoici la table members une troisième fois !

information_answer est une table associative entre information et members. Le fait d'y avoir ajouté un id fait qu'un member peut donner plusieurs réponses à une même information. C'est volontaire ?

4) Message
Tiens ! Une table/entité toute seule ! La pauvre ! Elle semble pourtant devoir être associée deux fois à la table members si j'en crois ses id_sender et id_receiver !


Je trouve encore qu'un password à 128 caractères ça fait beaucoup ! Même crypté en MD5, ça fait 128 bits, soit 32 caractères.

Par contre un uri à 10 caractères, c'est pas un peu juste ?

Bon courage pour la suite !

[Michaeljackfan]

pourquoi file au singulier et members au pluriel ?

C'est effectivement une erreur de ma part. Je corrige tout de suite.

Un group_access n'est associé qu'à un seul member. C'est le créateur du group_access ?

Non, c'est le membre du groupe. Puisque les group_access disent quel membre est associé à quel groupe. Il faudra donc autant de group_access par groupe qu'il y a de membres. Séparer les id_member par des virgules et faire un "explode()" par la suite est préférable ?
Le créateur du groupe est dans la table "group" (que je n'ai pas fait apparaître sur mes diagrammes).

D'après la cardinalité 1,1, un contact n'appartient qu'à un member. Quelle est la clé étrangère qui matérialise cette dépendance ?

En réalité un contact appartient à deux membres: celui qui a fait la demande de contact et celui qui a reçu cette demande.

Il serait bien sûr possible de faire un contact par membre, mais ça signifierai le double d'entrées et le risque que les relations entre-eux ne correspondent pas. C'est-à-dire que pour l'un des membres la demande est en attente, alors que pour l'autre elle a été acceptée (à cause d'une erreur mySQL ou de code).

information_answer est une table associative entre information et members. Le fait d'y avoir ajouté un id fait qu'un member peut donner plusieurs réponses à une même information. C'est volontaire ?

Un membre ne peut donner qu'une seule réponse à une information.
Mais si dans le futur je souhaite trier les réponses sans me soucier de l'id_member et id_information, cet id pourrait m'être utile. Et puis un int ne prend pas beaucoup de place.

Je trouve encore qu'un password à 128 caractères ça fait beaucoup ! Même crypté en MD5, ça fait 128 bits, soit 32 caractères.

Crypté en sha-512 ça fait 512 bits, soit 128 caractères.
Il parait que le MD5 n'est plus très sûr.

Par contre un uri à 10 caractères, c'est pas un peu juste ?

l'uri sera un numéro suivi d'une extension. donc ça ira de 000000.txt à 999999.txt.
Je pense que ça leur laisse assez de fichiers à uploader, surtout si je décide d'étendre ça avec des lettres (ça devient une base 36).
Mais ce n'est pas très clair, c'est vrai. je le remplace par "name".

c'est le label (TINYTEXT) qui sera le nom choisi par l'utilisateur et affiché sur la page.
Je préfère séparer les deux pour leur permettre de choisir librement le nom "affiché" des fichiers, sans restriction de caractères.


Bon, je vais faire un seul schéma avec toutes les tables et mettre des verbes. J'upload quand c'est fini.