Validation générale BDD mysql et 3 questions !
Résolu/Fermé
secropia1313
Messages postés
16
Date d'inscription
samedi 2 juin 2012
Statut
Membre
Dernière intervention
5 octobre 2018
-
29 oct. 2012 à 22:08
secropia1313 Messages postés 16 Date d'inscription samedi 2 juin 2012 Statut Membre Dernière intervention 5 octobre 2018 - 31 oct. 2012 à 19:07
secropia1313 Messages postés 16 Date d'inscription samedi 2 juin 2012 Statut Membre Dernière intervention 5 octobre 2018 - 31 oct. 2012 à 19:07
A voir également:
- Validation générale BDD mysql et 3 questions !
- Picasa 3 - Télécharger - Albums photo
- Mysql download - Télécharger - Bases de données
- Ai suite 3 download - Télécharger - Optimisation
- Validation des données excel - Guide
- Photorecit 3 - Télécharger - Visionnage & Diaporama
5 réponses
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.
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
Messages postés
16
Date d'inscription
samedi 2 juin 2012
Statut
Membre
Dernière intervention
5 octobre 2018
11
30 oct. 2012 à 15:33
30 oct. 2012 à 15:33
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 :
exemple PHP :
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 ! :)
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
Messages postés
16
Date d'inscription
samedi 2 juin 2012
Statut
Membre
Dernière intervention
5 octobre 2018
11
30 oct. 2012 à 16:41
30 oct. 2012 à 16:41
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.
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
Messages postés
16
Date d'inscription
samedi 2 juin 2012
Statut
Membre
Dernière intervention
5 octobre 2018
11
30 oct. 2012 à 19:35
30 oct. 2012 à 19:35
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 ;(
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 ;(
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
secropia1313
Messages postés
16
Date d'inscription
samedi 2 juin 2012
Statut
Membre
Dernière intervention
5 octobre 2018
11
31 oct. 2012 à 19:07
31 oct. 2012 à 19:07
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
Merci
Modifié par hellzil le 30/10/2012 à 12:55
ça c'est certainement une erreur, dans ces 150 colonnes il y a t'il des colonnes qui ont un point en commun?
Vous n'allez pas retenir toutes les pièces d'une référence produit par exemple mais uniquement la référence dans la colonne qui sera nommée produit, voire encore mieux faire une table produit qui retiendras toutes les références et associer celle ci à un achat, chaque achat est relié à un client, le but n'est pas de faire une liste du prévisionnel mais d'organiser les informations. Une table par entité permet d'organiser de façon logique. Les produits ne sont évidemment pas des clients donc ne doivent pas être mis ensemble.
Bref sans connaître tous les paramètres, je peut pas m'avancer bien sûr, chaque SI est adapté à une utilisation.