Découpage de table

Bonsoir, je suis actuellement en charge de programmer un site de rencontre.
Du fait que c'est mon premier site (j'ai fais du C++ avant mais bon, c'est un autre domaine), j'ai des questions qui restent sans réponse et surtout une.

Qui dit site de rencontre, dit profil utilisateur. Le fait est que le profil d'un membre se décompose en environ 50 données, réparties en 7 sections. J'avais pensé à deux méthodes:

- Soit tout stocker dans une table.
- Soit découper en 7 tables et en assurant la relation via les index.

Quel est la meilleure approche ?

Merci d'avance pour le temps que vous prendrez à me répondre.

Si les données sont toutes uniques pour chaque utilisateur , autant créer qu'une seule table

je pense pas que mettre des profile en base de donnée est une super idée.
La raison: imagine a chaque fois qu'une personne va faire une recherche, afficher un profil, editer son profile, tu auras une connection a la base de donnee. Multiplier par le nombre de visiteur, t'as base de donnée va sauté en moins de deux. je pense que tu as tout interer a sauvegarder les profiles dans des fchier xml ou autre. A la limite la bdd tu t'en sert comme backup des profiles.

Bonjour et merci pour vos réponses très instructives!

Je n'avais pas du tout pensé au XML et je pense que cette solution est en effet la meilleure approche qu'on pourrait avoir.

Merci encore à vous deux, sujet résolu :)

Désolé du double poste, mais j'évite d'ouvrir un nouveau thread pour cette question.

J'ai donc reflechis à l'utilisation de XML, et j'ai une petite question: cela ne va pas être couteux lors d'une recherche ?

Je veux dire, à chaques recherche, il faudra que j'ouvre un fichier xml, le parcours. Et ceux, pour chaque profils sur le site. C'est pas extremement couteux ?

c'est la que l'astuce opere :evilred:
tu as deux approchent. soi un arborescence de dossier (homme||femme /ville etc..) mais le probleme c'est que ta hiarchisation ne sera peut-etre pas la meme qu'un utilisateur lambda.
Apres tu as une aproch que j'appelle "l'approche secu". L'idee est d'utiliser une nomenclature de nom de fichier comme le numero de secu.
par example :

un homme sur paris brun sera 1 01 br.xml
une femme blonde de lille sera 2 10 bl.xml

(les espace c'est pour montre la segmentation)

donc, avec cette technique tu peux autant chercher des personnes precises que des chose vage.

par example :

n'importe qui sur paris sera [12]01[brbl].xml en regex

donc apres l'astuce est de faire un petit linux find avec ta regexp
find /dossier/ou/sont/mes/profiles/ -name find . -name 'regexp.xml'

dans notre cas la commande sera donc :
find /dossier/ou/sont/mes/profiles/ -name find . -name '[12]01[brbl]\.xml'

Le truc cool c'est qu'en plus avec une commande system ou autre, tu aura un array avec les resultats, ca facilite le fetch.

Citation:

---

Envoyé par mon_nom_est_personne

je pense pas que mettre des profile en base de donnée est une super idée.
La raison: imagine a chaque fois qu'une personne va faire une recherche, afficher un profil, editer son profile, tu auras une connection a la base de donnee. Multiplier par le nombre de visiteur, t'as base de donnée va sauté en moins de deux.

---

J'aimerais bien avoir une démonstration de ce que annonce :roll:
As ton avis le traitement par php de x fichiers XML est plus rapide qu'un SELECT bien fait ? Je demande à voir. A toi de me convaincre ;)

le probleme viens pas rellement au niveau de php mais au niveau de mysql
Prend une table de 10000 entrees, fait 1000 requetes en meme temps qui selectionne plein de champ avec des wheres et des order et regarde le load de ton server.
Apres xml etait un exemple, il y a d'autre solution comme convertir les donnee en binaire et faire des fseek etc.. apres c'est la magie de l'experience.

Citation:

---

Envoyé par mon_nom_est_personne

Prend une table de 10000 entrees, fait 1000 requetes en meme temps qui selectionne plein de champ avec des wheres et des order et regarde le load de ton server.
Apres xml etait un exemple, il y a d'autre solution comme convertir les donnee en binaire et faire des fseek etc.. apres c'est la magie de l'experience.

---

Je ne doute pas que ton expérience t'ai amenée a être confronté à ce type de questions et que tu ais trouvé tes solutions.

Mais peut être que LyX60 devrait porter son attention sur la qualité de ses requêtes et la structure de sa base afin d'en optimiser le fonctionnement, plutôt que de mettre en place des solutions qui risque d'être lourdes ?

Je pose la question, je n'affirme rien ;)

ca c'est sur, apres faut voir le tout, taille du projet, complexiter de ce dernier etc... Et ne t'en fait pas, je sais que dans 99% des cas, une sql bien ficelee ou une stored procedure font largement l'affaire.

Salut !

Perso j'opterais pour une base de données plutôt que des fichiers XML, et ce pour plusieurs raisons...

• Les bases MySQL peuvent tout à fait gérer des tables avec des milliers voir des millions d'entrées.
• Si l'on s'aperçoit dans un an qu'il manque un champ et qu'on souhaite ajouter une nouvelle info au profil des membres (exemple : sport pratiqué), alors il faudra reprendre tous les fichiers xml. Avec une base de données il suffira de rajouter un nouveau champ dans la table correspondante.
• Il sera beaucoup plus facile d'effectuer une recherche multi-critères sans se limiter à quelques champs, et si la structure de la base est bien faite (clés étrangères, index pour les recherches), alors les requêtes seront rapides
• Enfin, il est tout a fait possible d'utiliser un système de cache qui limitera grandement le nombre de requêtes.

Voilà qq arguments en faveur des BDD ;)...
C'est vrai que les fichiers xml sont très pratiques dans certains cas : échange de données, flux rss, fichiers de config, etc. Une base est faite pour stockées de données de manière structurée et cohérente, ce qui à mon avis est beaucoup plus simple d'utilisation. Mais ca ne reste qu'un avis parmi tant d'autre...

A++