Discussion :

[kxxx78]

Bonjour tout le monde !

Je met actuellement en place une base de données pour un site de rencontre.

J'ai donc actuellement.

1 table (map_villes) de donné static qui contient tout les villes, code postal, latitude etc
1 table (users) qui contient la liste des utilisateur avec les info général ( tt les pseudo, password, adresses, etc)
1 table (parrainage_request) qui contient les demande de parrainage ( son volume devrait augmenter doucement pour l'instant 300 entrées )
1 table (parrain) qui contients les parains actuelles ( la aussi trés peu de donné car dans notre system un parrain est valide 15 jours )

et le point qui était bancale était qu'à chaque utilisateur j'ajoutais 4 tables.

1 table (pseudo_de_l'user_msg) pour les message que ce membres à envoyé aux autres membres.
1 table (pseudo_de_l'user_contact) pour les contacts de ce menbre
1 table (pseudo_de_l'user_check) pour les choix de l'utilisateur ( l'utilisateur choisi sur notre site les personne qui lui plaise et les choix sont enregistré dans cette base)
1 table (pseudo_de_l'user_visite) qui enregistre les personne qui ont visité ( en gros qui on regarder) le profil du membre en question.

Je comptai évoluer vers l'architecture suivante

8 tables

je garderais les 4 premiers tables citées dessus :

1 table (map_villes) de donné static qui contient tout les villes, code postal, latitude etc
1 table (users) qui contient la liste des utilisateur avec les info général ( tt les pseudo, password, adresses, etc)
1 table (parrainage_request) qui contient les demande de parrainage ( son volume devrait augmenter doucement pour l'instant 300 entrées )
1 table (parrain) qui contients les parains actuelles ( la aussi trés peu de donné car dans notre system un parrain est valide 15 jours )

et au lieu de créer 1 table par users je pensait faire 4 tables qui contiendrait le même type de données mais pour TOUT les utilisateurs ( de cette façon je pense rester à 8 tables sauf si j'ajoute de nouvelle fonction) .

Les 4 dernières tables serais donc:

1 table (all_msg) pour tout les messages.
1 table (all_contact) pour tout les contacts.
1 table (all_check) pour tout les choix
1 table (all_visite) qui enregistres tout les visite.

J'ai peur que la 2 ieme solution soit plus dure à gérer ( quoi qu'en mettant des index et des vues ca devrait aller) dans un premier temps, mais à long terme elle me paraît beaucoup plus performantes.
Aussi si je garde l'architecture actuelle, j'ai peur que si par exemple je me retrouve un jour à vouloir afficher le nombre total de rencontre fait sur notre site je doive me retrouvé à effectuer des requetes sur tout les tables pseudo_user_contact ce qui risque d'etre catastrophique en terme de performance !

Encore merci et bravo a ceux qui ont eut la force ( et le temp surtout) de tout lire !

[CinePhil]

J'ai donc actuellement.

1 table (map_villes) de données statiques qui contient toutes les villes, code postal, latitude etc.
1 table (users) qui contient la liste des utilisateurs avec les infos générales ( ts les pseudos, passwords, adresses, etc)
1 table (parrainage_request) qui contient les demandes de parrainage ( son volume devrait augmenter doucement pour l'instant 300 entrées )
1 table (parrain) qui contient les parains actuels ( la aussi trés peu de données car dans notre système un parrain est valide 15 jours )

A quoi sert la table parrain ?
Un parrain n'est-il pas un user qui a effectué un parrainage_request ?

et le point qui était bancal était qu'à chaque utilisateur j'ajoutais 4 tables.

C'est plus que bancal, c'est carrément casse-gueule !

au lieu de créer 1 table par users je pensais faire 4 tables qui contiendraient le même type de données mais pour TOUS les utilisateurs

C'est plutôt comme ça qu'il faut faire oui.

Les 4 dernières tables seraient donc:

1 table (all_msg) pour tous les messages.
1 table (all_contact) pour tous les contacts.
1 table (all_check) pour tous les choix
1 table (all_visite) qui enregistre toutes les visites.

La table all_msg, que tu pourrais simplement nommer message répond à l'association suivante :
user -0,n----envoyer_message----0,n- user

Sa clé primaire est donc composée des identifiants de l'expéditeur et du destinataire, lesquels doivent être différents. Ainsi tu peux effectivement stocker tous les messages de tous les utilisateurs dans une seule table.

Idem pour les tables des contacts et des visites :
user -0,n----Contacter----0,n- user
user -0,n----Visiter----0,n- user

Par contre, la table des choix, c'est quoi ?
Les préférences de l'utilisateur sur sa cible ? (Blonde, yeux bleus, mince, intelligente, cultivée... comment ça ça n'existe pas ? )
Si les critères de choix sont préprogrammés, tu devrais aussi avoir une table pour ces critères et il y aurait alors une association :
user -0,n----valoriser----0,n- critère
Et ta table de choix correspondrait à la matérialisation de cette association.
Si les choix peuvent être multiples (j'aime bien aussi les brunes aux yeux verts ! ), ce sera plus compliqué car la valeur entrera dans la composition de la clé primaire de la table.

J'ai peur que la 2 ieme solution soit plus dure à gérer

Moi ça me semble plus simple !

mais à long terme elle me paraît beaucoup plus performantes.

Ca c'est sûr !

[kxxx78]

Merci pour ta réponse rapide !
Bon je vais déja essayé de faire moins de fautes ^^.

pour ce qui est de ta remarque sur :
(je sais pas faire de citation dois yavoir des balises spécifiques désolé.)

--------------------------------------------------------------------
A quoi sert la table parrain ?
Un parrain n'est-il pas un user qui a effectué un parrainage_request ?
---------------------------------------------------------------------

==> Tu sous entends que je peux supprimer la table parrain si je rajoute un ou deux champs dans la tables users ? ( c'est vrai que ca doit être possible facilement ). Plus que 7 tables ?


ensuite :

---------------------------------------------------------------------
La table all_msg, que tu pourrais simplement nommer message répond à l'association suivante :
user -0,n----envoyer_message----0,n- user

Sa clé primaire est donc composée des identifiants de l'expéditeur et du destinataire, lesquels doivent être différents. Ainsi tu peux effectivement stocker tous les messages de tous les utilisateurs dans une seule table.

Idem pour les tables des contacts et des visites :
user -0,n----Contacter----0,n- user
user -0,n----Visiter----0,n- user
------------------------------------------------------------------------

==> J'ai un peu du mal avec les 0-n mais le but serait d'optimiser les performances en mettant des clés primaires sur chaque entrées ( si martin envoi un message a francois j'aurait quelque chose comme martin_to_francois en clé ?)

je t'avou que j'ai pas énormément de connaissances en informatiques à la base j'ai fait une formation électronique ( grosse erreure ^^ ) donc UML, Merise ca m'est un peu inconnu je pense que les notations que tu me donnes proviennent de ces méthodes. Donc ca n'est pas forcément trés clair pour moi.

En même temps je viens de voir que ya tout ce qui faut pour apprendre ces méthodologies sur votre site, je vais essayer de survoler (pas trop mais histoire de comprendre pourquoi entre nous ya autant de n, lol allez un jeux de mot et quelques fautes d'ortographes gratuits ! ), ca devrait pas me faire du mal.

pour ce qui est de ta remarque par rapport à la table choix :

--------------------------------------------------------------------------
Par contre, la table des choix, c'est quoi ?
Les préférences de l'utilisateur sur sa cible ? (Blonde, yeux bleus, mince, intelligente, cultivée... comment ça ça n'existe pas ? )
Si les critères de choix sont préprogrammés, tu devrais aussi avoir une table pour ces critères et il y aurait alors une association :
user -0,n----valoriser----0,n- critère
Et ta table de choix correspondrait à la matérialisation de cette association.
Si les choix peuvent être multiples (j'aime bien aussi les brunes aux yeux verts ! ), ce sera plus compliqué car la valeur entrera dans la composition de la clé primaire de la table.
--------------------------------------------------------------------------

==> Pour l'instant le système est trés basique et ne contient que 2 ou 3 colonnes, nous ne prenons pas encores en comptes les descriptions physiques, les membres ont accés au profil ( photo et description ) de la personne qu'il regarde et dise si oui ou non la personne leur plait ( c'est résumé assez rapidement mais en fait cette table ne contient pas grand chose de plus que les 2 pseudos des personnes ). Mais si je croise une brune aux yeux verts je te ferais signe

Petite rectification j'ai bien dit gérer dans un premier temps ( à une parenthèse prés ca m'apprendra à mal m'exprimer lol )

Mais il est clair que vaut mieux construire des bases solides dés le départ même si je doit y passer plus de temps.

Voila encore merci pour ta rapidité et le temps passé sur mes problèmes !

[CinePhil]

(je sais pas faire de citation dois yavoir des balises spécifiques désolé.)

Juste au dessus de l'éditeur te permettant d'écrire un message, tu as une barre d'outils qui se termine par une icône ressemblant à une bulle de dialogue de bande dessinée et une autre représentant un dièse. La première te permet de faire des citations et la seconde de taper proprement du code informatique qui de plus sera interprété par l'éditeur selon le forum dans lequel tu te trouves et appliquera une mise en forme.

--------------------------------------------------------------------
A quoi sert la table parrain ?
Un parrain n'est-il pas un user qui a effectué un parrainage_request ?
---------------------------------------------------------------------

==> Tu sous entends que je peux supprimer la table parrain si je rajoute un ou deux champs dans la tables users ? ( c'est vrai que ca doit être possible facilement ). Plus que 7 tables ?

Non pas ajouter une colonne (et pas un champ !) dans la table users mais je me demandais si ça ne faisait pas doublon avec la table parrainage_request.
Tu peux donner la structure de ces deux tables et décrire comment tu t'en sers ?

==> J'ai un peu du mal avec les 0-n mais le but serait d'optimiser les performances en mettant des clés primaires sur chaque entrées ( si martin envoi un message a francois j'aurait quelque chose comme martin_to_francois en clé ?)

Je reprends la première association que j'ai décrite :
user -0,n----envoyer_message----0,n- user

Ceci pourrait donner les tables suivantes :
user (u_id, u_nom, u_prenom, u_pseudo...)
message (m_id_expediteur, m_id_destinataire, m_contenu, m_lu)
La clé primaire identifiant le user dans table user référence les deux clés étrangères de la table message, lesquelles clés étrangères constituent ensemble la clé primaire de la table message.
Quand il y a une cardinalité maximale à n des deux côtés d'une association, on crée une table associative dont la clé primaire est constituée des identifiants des deux tables entrant en jeu dans l'association.

je t'avou que j'ai pas énormément de connaissances en informatiques à la base j'ai fait une formation électronique ( grosse erreure ^^ ) donc UML, Merise ca m'est un peu inconnu je pense que les notations que tu me donnes proviennent de ces méthodes. Donc ca n'est pas forcément trés clair pour moi.

En même temps je viens de voir que ya tout ce qui faut pour apprendre ces méthodologies sur votre site, je vais essayer de survoler (pas trop mais histoire de comprendre pourquoi entre nous ya autant de n, lol allez un jeux de mot et quelques fautes d'ortographes gratuits ! ), ca devrait pas me faire du mal.

Effectivement, je te conseille notamment la lecture du tutoriel de SQLPro sur la modélisation Merise, ainsi d'ailleurs que l'ensemble de son blog qui est une mine d'or du SQL.

==> Pour l'instant le système est trés basique et ne contient que 2 ou 3 colonnes, nous ne prenons pas encore en compte les descriptions physiques, les membres ont accés au profil ( photo et description ) de la personne qu'il regarde et dise si oui ou non la personne leur plait ( c'est résumé assez rapidement mais en fait cette table ne contient pas grand chose de plus que les 2 pseudos des personnes ).

2 choses :
1) Dire "pour l'instant" en modélisant une base de données, ça va quand on est encore en phase de conception/modélisation. Mais une fois que la base est terminée, en principe on ne touche plus au modèle, comme je l'ai expliqué par ailleurs tout récemment. C'est pour ça que je préconisais la création d'une table de critères qui pourra en contenir autant que ton imagination pourra en créer (qui sait un jour pourquoi pas un critère "planète d'origine" ? Je me souviens d'une Twilek rencontrée sur Tatooine... )

2) Si je comprends bien, ta table actuelle répond actuellement juste à l'association
user -0,n----Choisir----0,n- user
C'est le même système que les autres associations que j'ai déjà décrites.

[kxxx78]

Rebonjour,

Merci pour les citations ca sera plus lisible pour tout le monde !

Citation:
--------------------------------------------------------------------
A quoi sert la table parrain ?
Un parrain n'est-il pas un user qui a effectué un parrainage_request ?
---------------------------------------------------------------------

==> Tu sous entends que je peux supprimer la table parrain si je rajoute un ou deux champs dans la tables users ? ( c'est vrai que ca doit être possible facilement ). Plus que 7 tables ?


Non pas ajouter une colonne (et pas un champ !) dans la table users mais je me demandais si ça ne faisait pas doublon avec la table parrainage_request.
Tu peux donner la structure de ces deux tables et décrire comment tu t'en sers ?

Alors la table Parrainage request contient le login du parrain , un identifiant unique et l'adresse mail du filleul .

L'identifiant unique sert au faite que nous offrons au parrain le droit de parrainez des filleuls de manière anonyme.

Ensuite lorsqu'un filleul s'inscrit nous lui demandons l'identifiant unique ( qu'il recoit dans le mail lui indiquant qu'il a été parrainez ) de cette facon si un filleul est parrainez par 15 parrains, un seul parrain se trouvera validé : celui dont l'id unique à été saisie par le filleul lors de l'inscription.

La table Parrain contient juste le login du parrain (que nous utilisons comme clé unique mais nous pensont mettre un ID car en terme de performance cela parait plus efficaces ) ainsi que le nombre de jour restant au parrain ( un parrainage dure 15 jour c'est à dire que pendant 15 jour le parrain en question bénificiera d'avantage ).
C'est pour cela que il suffirait juste d'inclure dans la table user la colonne jour_restant qui est actuellement la seul colone de la table parrain en plus de la clé primaire qui est le login pour pouvoir supprimer la table parrain.
La table parrain contient actuellement le login et le nombres de jours restants.


J'envisage donc bien de passer à 7 tables ( suppressions de la table parrain )
je rajouterais aussi un colonne dans la table parrainage request qui me
permettra de garder en mémoire si un filleul c'est inscrit ou non ( juste un boolean bête et méchant devrait suffir. )

Citation:
==> J'ai un peu du mal avec les 0-n mais le but serait d'optimiser les performances en mettant des clés primaires sur chaque entrées ( si martin envoi un message a francois j'aurait quelque chose comme martin_to_francois en clé ?)

Je reprends la première association que j'ai décrite :
user -0,n----envoyer_message----0,n- user

Ceci pourrait donner les tables suivantes :
user (u_id, u_nom, u_prenom, u_pseudo...)
message (m_id_expediteur, m_id_destinataire, m_contenu, m_lu)
La clé primaire identifiant le user dans table user référence les deux clés étrangères de la table message, lesquelles clés étrangères constituent ensemble la clé primaire de la table message.
Quand il y a une cardinalité maximale à n des deux côtés d'une association, on crée une table associative dont la clé primaire est constituée des identifiants des deux tables entrant en jeu dans l'association.

D'accord j'aurai donc une clé étrangere par utilisateur sur ma table message que j'utiliserai pour former une clé primaire, cela ne me parait pas compliqué d'un point de vue théorique, je regarderai comment faire cela les info ne doivent pas manquer sur le net .

Citation:
je t'avou que j'ai pas énormément de connaissances en informatiques à la base j'ai fait une formation électronique ( grosse erreure ^^ ) donc UML, Merise ca m'est un peu inconnu je pense que les notations que tu me donnes proviennent de ces méthodes. Donc ca n'est pas forcément trés clair pour moi.

En même temps je viens de voir que ya tout ce qui faut pour apprendre ces méthodologies sur votre site, je vais essayer de survoler (pas trop mais histoire de comprendre pourquoi entre nous ya autant de n, lol allez un jeux de mot et quelques fautes d'ortographes gratuits ! ), ca devrait pas me faire du mal.

Effectivement, je te conseille notamment la lecture du tutoriel de SQLPro sur la modélisation Merise, ainsi d'ailleurs que l'ensemble de son blog qui est une mine d'or du SQL.

J'ai commencé à bouquiner le pdf de Michel DIVINÉ, mais je jetterais un coup d'oeil sur ta source, Merci.

Citation:
==> Pour l'instant le système est trés basique et ne contient que 2 ou 3 colonnes, nous ne prenons pas encore en compte les descriptions physiques, les membres ont accés au profil ( photo et description ) de la personne qu'il regarde et dise si oui ou non la personne leur plait ( c'est résumé assez rapidement mais en fait cette table ne contient pas grand chose de plus que les 2 pseudos des personnes ).

2 choses :
1) Dire "pour l'instant" en modélisant une base de données, ça va quand on est encore en phase de conception/modélisation. Mais une fois que la base est terminée, en principe on ne touche plus au modèle, comme je l'ai expliqué par ailleurs tout récemment. C'est pour ça que je préconisais la création d'une table de critères qui pourra en contenir autant que ton imagination pourra en créer (qui sait un jour pourquoi pas un critère "planète d'origine" ? Je me souviens d'une Twilek rencontrée sur Tatooine... )

2) Si je comprends bien, ta table actuelle répond actuellement juste à l'association
user -0,n----Choisir----0,n- user
C'est le même système que les autres associations que j'ai déjà décrites.

Pour la table critère il faudrait donc que je crées une table avec autant de colonnes que d'attribut physique que je veux stocker pour aprés pouvoir effectuer des recherches par criteres ?

Le problème étant qu'actuellement l'application ne permet pas à l'utilisateur de définir ses critères physique...
Cependant à long terme cette fonction peut etre trés intéressante.

Aussi à long terme je prévois 3 type de recherche, dois je créer 3 tables prévu à leur effet.

Je détail:
une recherche par pseudo
une table avec juste les pseudo et id user serait suffisante

une recherche rapide
une table avec l'age le lieu et le le sexe et l id user serait suffisante

une recherche détaillé
une table avec les critères physique (qui en gros contiendrait un peu le contenu des 2 table cité ci dessus + les critères physiques) serait suffisante

si je fonctionne comme ca la table user contiendra donc plus que les info utilisé par mon code en interne (login, password etc)

Est ce la bonne approche pour arrivé a une optimisation des temps de réponses ? (Tout le monde sait que sur le site de rencontre la recherche c'est 99% du temp passé sur le site il est donc important de prendre ce parametre en considération)

Je suis bien conscient que c'est trés peu claire mais étant donné que c'était mon premier job ou j'était à la fois au dev et à la base de donnée j'ai attaqué le problème à l'envers et je vais me retrouver à regratter toutes mes requêtes SQL. Ca m'apprendra à tout faire à l'envers.

En tous cas merci beaucoup depuis hier ma vision de mon modèle de données a beaucoup évolué ( et continue encore ) J'espère juste repartir avec une vision d'un datamodel performant cette fois pour ne pas avoir à refaire cette tâche plus tard !