Validation générale BDD mysql et 3 questions ! Résolu/Fermé

Question

Bonjour, 

je suis sur le point de finaliser une structure de BDD Mysql pour un outil en ligne.
Je ne voudrait pas recommencer trois fois ! Alors j'aimerais vous exposer le tout de façon générale et s'il y a des trucs à proscrire carrément j'aimerais bien être mis au courant :)

Voilà, c'est tout simple j'ai une table client avec tout plein de préférence et leur coordonné formant du même coup leur profil.   (activité préféré, pour les besoins de la cause) 
 ( comprend 150 colonnes ! )

J'ai une autre table avec tout plein d'activité. Ces activités comprennent évidement tout plein de qualité. ( sportive, artistique, etc..)

Dans un script ( toujours en PHP ) je vais donc leurs proposer de plus en plus des activités qui corresponde à leurs goût. Car à chaque nouvelle activité il pourront mette leur appréciation et ainsi préciser leurs profil. Les nouvelle activité que je leur proposerai seront de plus en plus '' idéal '' pour eux et il les évaluerons aussi..Etc.. Etc..

( j'ai gobé tous ce que je pouvait sur le partitionnement et indexation de table et fait beaucoup de recherche )

Voici mes interrogations :
 
.1 Pour traiter leurs préférence et en ressortir des nouvelles activités à leur offrir je vais utiliser un code PHP avec des comparaisons qui donnerons un groupe d'activité et sur ce groupe trois ( par exemple ) activité en sortirons. 

   Étant donné que des requête SQL ET PHP peuvent faire certaine tâche, quelle codage est le plus efficace ( par soucis d'économie de temps de calcul ) PHP ou Mysql.
( je pensait au sous-requête et comparaison sql VS PHP ) 

.2 Ma table client avec leurs coordonné et profil contient environ 150 colonnes. Je ne sait pas si c'est trop. Je veux dire, je ne vois pas l'intérêt de la proportionner. Je vais plutôt indexé les colonnes d'on je me sert souvent et m'arranger pour ne pas qu'il y ait une même information qui se répète dans plusieurs ligne.

 Qu'est-ce que vous en pensé ? Et d'après vous après 15 000 clients est-ce que je devrais modifier ma structure de table pour ne pas que ma table est un jours 100 000 lignes ( 100 000 clients )

.3 Dans la logique du système, le client peut choisir de ce faire initié à une nouvelle activité 1 fois par semaine ou 1 fois par moi. Alors j'ai décidé de stocker les numéros d'activités qu'il a adorer et déjà fait ( par exemple ) dans la colonne X. Alors le contenue de la cellule  X pourrait ressembler à : a1, a7, a3 et la semaine suivante : a3, a4,a9
Ainsi je n'aurai qu'à scanner le contenu de la cellule  et avec '' explode '' je produit un tableau que je trie avec les préférences du client et divers condition. 
Avantage : je n'ai pas besoin de créer une nouvelle colonne à chaque activité que le client '' aime '' , Cela ne finirais plus et je préfère une table relativement stable pour touts mes clients.

 Est-ce qu'il y aurait une meilleur solution ?

Voilà je sait que ça fait beaucoup à lire mais je me voyais mal faire plus cours.

Merci :)

Configuration: Windows 7 / Firefox 16.0

hellzil · Answer

Salut,

et s'il y a des trucs à proscrire carrément j'aimerais bien être mis au courant :)
Oui tout à fait comme ceci, ça faut pas faire

Voilà, c'est tout simple j'ai une table client avec tout plein de préférence et leur coordonné formant du même coup leur profil. (activité préféré, pour les besoins de la cause)
( comprend 150 colonnes ! )
J'ai une autre table avec tout plein d'activité. Ces activités comprennent évidement tout plein de qualité. ( sportive, artistique, etc..) 

Vos 2 tables ne sont pas viables, il faut faire une analyse dusystème d'informations pour :
1_trouver toutes les informations pertinentes(maintenant ou dans le futur)
2_repérer les doublons, les données qui doivent être divisées ou regroupées 
3_Établir des entités par regroupement thématique
4_Établir des liens logique entre ces entités

Vous avez la méthode Merise qui permet de le faire.

Passer outre cette analyse(essentielle) vous expose à de graves problèmes dont les moindres seront un coût et temps accru de développement ainsi qu'à l'utilisation.

L'analyse permet donc entre autre de vous retrouver avec un programme qui sera tellement compliqué, lourd et inadapté qu'utiliser des armoires en fer avec des casiers sera plus rapide qu'utiliser l'informatique.


Étant donné que des requête SQL ET PHP peuvent faire certaine tâche, quelle codage est le plus efficace ( par soucis d'économie de temps de calcul ) PHP ou Mysql.
( je pensait au sous-requête et comparaison sql VS PHP ) 
Vos connaissez pas grand chose au développement... Il n'y a pas de PHP Vs SQL, le but le plus fréquent de PHP est de faire des requêtes SQL, ils sont complémentaires et non concurrents: PHP permet de faire la liaison avac la base de données(en écrivant du SQL) et le navigateur de l'utilisateur(en écrivant du HTML). Un de mes profs d'informatique me disait la seule fonction utile de php se nomme " echo() ", il n'éxagérait pas tant que ça.

Qu'est-ce que vous en pensé ? Et d'après vous après 15 000 clients est-ce que je devrais modifier ma structure de table pour ne pas que ma table est un jours 100 000 lignes ( 100 000 clients ) 

Certainement pas, le meilleur moyen d'aller dans le mur. Soit vous faites un truc correct dés le début et envisagez les possibilités dans les prochaines dont vous pourrez avoir besoin(les 2 par l'analyse), soit vous ne faites rien car vous perdrez un temps fou en développement pour un programme qui ne fonctionnera pas, produira des erreurs(une erreur dans la table et toute la tables  bonne à jeter), ou fera un programme tellement complexe à utiliser qu'il sera incompréhensible et lent.
Rapatrier les informations vers un autre Modèle Conceptuel de Données est rarement faisable sans peine, risque de faire perdre une partie voire totalité des données.
Avant de penser développement il faut organiser les informations de façon logique, logique informatique et non humaine qui ne fonctionnes pas pareille et où l'ordinateur peut classer mais pas savoir ce que sait l'humain...

Est-ce qu'il y aurait une meilleur solution ? 
Que de faire un Système d'Information sans aucune analyse oui certainement.
Imaginez la sécu si leur base de données était pas complétement adaptée, que le temps de recherche, modifications des informations était lent à cause d'une organisation du programme désordonnée, que la sécu au bout de 3 ans devait tout casser pour reconstruire en essayant de transférer les données de l'ancien système vers le nouveau...
Bref pas viable tout ça et une perte de temps et d'argent, une organisation inneficace au lieu d'un système qui marche tout seul.
Pour votre Système d'Information et de Gestion de ases de Données, comme pour tout les autres, c'est pareil.
Donc analysez, triez et modélisez quelques explications bien que succintes devrait vous éclairer ici:

http://www.commentcamarche.net/contents/merise/mcd.php3

ps: bien sûr c'est un métier, imaginez qu'il n'y ait pas d'architecte pour faire les plans d'un immeuble, ceux ci ce casseraient la gueule plus souvent.

secropia1313 · Answer

Merci beaucoup de la réponse, avant d'aller travailler ce que tu m'a proposé il y a quelques précision à faire au cas ou je m'aurais mal exprimé.

1. Pour les '' opérations ''  SQL  VS  PHP pour temps de réponse, je ne voudrait pas te contredire mais j'ai lu ( peut-être à tord ) que c'était possible dans les deux langage.( je sait qu'SQL est est utilisé par php pour communiquer avec la base de donné.  exemple SQL : 

SELECT f.foo, f.bar, (f.foo/f.bar) as quotient 
FROM foo f 
order by quotient;

exemple PHP :

<?php
// Déclaration des variables mathématiques
$a = f.foo;
$b = f.bar;

$c = $a * $b;

$c = $a / $b;

$c = $a - $b;
//etc...

?>

Je suis parfaitement conscient que dans une page php les commandes sql ce feront avec php mais dans le cas du premier exemple ---) sql fait un '' calcul '' et il ne reste qu'à mettre le résultat dans une variable php pour afficher le résultat. Dans le deuxième cas--) php prend des valeurs présente dans la base de donné et fait le calcul lui même pour afficher le résultat.Peut-être ai-je mal compris. Cela fait plusieurs site que je développe avec php mysql mais c'est ma première grosse base de donnée.

2. Je me suis mal exprimé quand je parlait de '' modifier ma structure si je prévois dépasser le X nombre de membres'' . Ce que je voulais dire est de savoir si je devrai partitionner la table ou un truc du genre après par exemple 10 000 membre donc 10 000 ID donc 10 000 ligne. Autrement dit prévoir le coup et construire ma table dès maintenant en conséquence. On parle bien du nombre de ligne ici et pas du nombre de colonnes. ( ce que tu as déjà répondu en me proposant la méthode Merise, ou étais-ce plus spécifiquement pour les colonnes )

3. Pour le nombre de colonnes il y à 20 colonnes qui comprennent des coordonné et détail perso du client, pour 50 autres colonnes ce sont ses goût perso vis à vis des activités en générale et 50 autre colonnes qui spécifie la fréquence et la façon d'on il aimerait que le résultat des activités qu'on lui propose soit présenté.

Donc, tout les colonnes de cette table ont un lien avec le client point. Il n'y as pas d'activité proprement dit, les activités sont détaillé et codé dans l'autre table '' activité ''. Alors, une table pour le profil client et une table pour le profil activité. Je ne vois pas , pour l'instant, l'intérêt de créer des jointures avec 2 autres tables séparer du genre 20  50  50  au lieu de faire des indexes sur quelques colonne de ma table '' profil '' à 120 colonnes par exemple.

Bon comme je disait ce sont quelques précisions qui comprennent surement quelques erreurs. C'est la raison pour laquelle j'ai mentionné que j'allais travaillé sur  la méthode Merise et revenir avec une analyse plus professionnel.
Mais si jamais il y une de mes précisions qui change la donne on ce tient au courant. ( les autres post devrait être plus court !  :)

secropia1313 · Answer

J'ai survoler la méthode merise et voilà d'après-moi le questionnement qui se pose.

Pour faire très simple je crois qu'on peut utiliser un petit exemple bien pratique et concret.

Donc, dans mon cas j'ai une table pour le profil du client incluant ses goûts, les coup de coeur ( activité )  des deux dernier mois, ses handicaps et quelques autres préférences perso.
( tous est basé sur ses intérêts par rapport au domaine '' activité récréative '')

Une autre table avec tous ses fameuses activités récréatives, leur champs d'application, ce qui les démarques, leur type, etc..

Et une troisième avec quelques modèles d'activités récréatives prédéfinie sur lequel le script va se basé pour remplis le calendrier du client avec tout plein d'activité.

La question à ce poser est de savoir si dans ce cas il est mieux de '' divisé '' la table activité en plusieurs table du genre activité sportive, artistique, musicale, etc.. ou de mettre un index sur la colonne type d'activité dans la table unique activité récréative.

Dans le cas ou il y a plusieurs table une contrainte supplémentaire apparait quand ont veut sélectionné une activité récréative '' sportive '' .. il faudra spécifier la table '' sportive ''. Donc, dans la table profil client à la colonne ou le client à enregistrer tous ces '' coup de coeur de la semaine '' l' ID de l'activité en question ne suffira plus, il faudra le nom de sa catégorie aussi. ( surement en utilisant des '' jointure de table '' )

Cas type je crois. Qu'est-ce vous en pensé. Est-ce qu'on est à une frontière ou deux solutions peuvent être envisageable. Une avec '' index ''  et l'autre avec plusieurs jointures de table, etc... À Quelle point une grosse table indexé peut être un problème. 150 colonne ces carrément trop pour un profil..Il faut absolument '' partitionné '' le profil client ? 

Merci de vos lumière.

secropia1313 · Answer

Je viens de trouver des info intéressantes. De base, ont peut dire que le poids d'une ligne ne doit pas dépasser 8ko soit 50% de la taille d'une page sql. 
idéalement en dessous de 4ko ainsi deux lignes pourront être '' traité '' dans une page sql. Une de mes  lignes de la plus gosse table fait 3ko.
 ( soit celle profil client ) Il y aura quelques requête d'écriture mais le reste ce fera en lecture seulement. Sachant que je suis en inoDB en que les verrou s'effectue uniquement sur les lignes et non sur la table entière cela est parfait car deux clients différents ne seront pas autoriser à travailler sur le même  profil.

Pour les autres tables quelques jointures et index suffirons d'après-moi étant donné que le nombre de colonne sera extrêmement limité et que les requêtes ce résumeront à la lecture. Ainsi une recherche indexé du genre '' activité récréative sportive '' et '' extérieur '' ce fera très bien.

Mon manque d'expérience peut me faire dire des ânerie aussi  ;(

secropia1313 · Answer

Bon ben , je doit être trop long dans mes textes...J'ai déjà eu une bonne piste je vais la suivre et je pourrai revenir avec des questions plus précise, moins générale, si je ne trouve pas de réponse avec google.

Merci

Validation générale BDD mysql et 3 questions !

5 réponses

Discussions similaires