Nbre de tables et performances [Résolu]

[shkyo]

Bonjour à tous,

Je suis en train de penser sur le papier une future BD MySQL5 qui sera nourrie par des formulaires gérés en PHP5, et sachant que je suis débutant, plusieurs questions basiques me viennent...

En termes de performances et d'efficacité, il vaut mieux une seule BD avec pas mal de tables (environ une bonne vingtaine) ou plusieurs petites BD avec moins de tables ???

Et dans une table données, si un (ou plusieurs) nouveau champ est ajouté après quelques temps d'exploitation et donc une certaine quantité de données, est-ce que cela se fait sans problème (avec phpadmin par ex) et sans conséquences sur les perfs ?

J'espère que je suis assez clair, sinon dites-le moi, je préciserais mes pensées...

Merci d'avance de vos réponses.

[DBProg]

Bonjour !

Envoyé par shkyo

Bonjour à tous,

Je suis en train de penser sur le papier une future BD MySQL5 qui sera nourrie par des formulaires gérés en PHP5, et sachant que je suis débutant, plusieurs questions basiques me viennent...

Parfait, allons-y !

Envoyé par shkyo

En termes de performances et d'efficacité, il vaut mieux une seule BD avec pas mal de tables (environ une bonne vingtaine) ou plusieurs petites BD avec moins de tables ???

Non, pas de soucis, t'inquiètes pas, ce n'est pas avec une petite vingtaine de table que ça va s'écrouler, c'est presque rien ! Il ne faut pas perdre le sens de la base non plus, une base est sensée regroupée un ensemble d'informations qui "communiquent" les unes entre elles. D'un point de vue de concéption ça n'aurait pas vraiment de sens de créer plusieurs bases, découpant ainsi l'information, pour au final, ne plus se retrouver avec quelque chose de cohérent dans aucune des bases.

De plus, tu perdras largement en performance si tu dois accéder à des bases différentes pour les requêtes, et certaines requêtes deviendront probablement bien plus compliquée à créer.

Envoyé par shkyo

Et dans une table données, si un (ou plusieurs) nouveau champ est ajouté après quelques temps d'exploitation et donc une certaine quantité de données, est-ce que cela se fait sans problème (avec phpadmin par ex) et sans conséquences sur les perfs ?

On peut dire oui et non. Il y a de forte chance que les colonnes ajoutées à postériori soient placées à "DEFAULT NULL", dans quel cas tous les anciens enregistrements seront placés à NULL (dans cette colonne j'entends). Après tout dépend des traitements que tu en fais, surtout de tes SELECT. Si tu faisais des SELECT * tu rapporteras une colonne en plus, dans les jointures idem, etc... tu comprends ?

Ce ne sera pas forcément significatif, comme je dis tout dépend de tes requêtes. Mais quoi qu'il en soit, n'hésite pas à ajouter tes colonnes si tu en as besoin bien sûr, c'est fait pour, mais c'est d'un point de vue méthode toujours mieux d'y avoir pensé au début (je pense)

Le plus important est de bien choisir le type de données aussi. Des choses bêtes, comme tinyint, mediumint, int, peuvent influer sur la qualité des requêtes et la place prise par ta base, si le volume de données commence à devenir conséquent. Mais autant prendre les bonnes habitudes tout de suite

Envoyé par shkyo

J'espère que je suis assez clair, sinon dites-le moi, je préciserais mes pensées...

Merci d'avance de vos réponses.

Idem
De rien !

[shkyo]

Envoyé par dbprog

Non, pas de soucis, t'inquiètes pas, ce n'est pas avec une petite vingtaine de table que ça va s'écrouler, c'est presque rien ! Il ne faut pas perdre le sens de la base non plus, une base est sensée regroupée un ensemble d'informations qui "communiquent" les unes entre elles. D'un point de vue de concéption ça n'aurait pas vraiment de sens de créer plusieurs bases, découpant ainsi l'information, pour au final, ne plus se retrouver avec quelque chose de cohérent dans aucune des bases.

De plus, tu perdras largement en performance si tu dois accéder à des bases différentes pour les requêtes, et certaines requêtes deviendront probablement bien plus compliquée à créer.

Je m'en doutais un peu, mais bon en tant que newbie, je préfère poser la question avant plutôt que de me dire "oups" quand la BD a déjà 100000 enregistrements...

Envoyé par dbprog

On peut dire oui et non. Il y a de forte chance que les colonnes ajoutées à postériori soient placées à "DEFAULT NULL", dans quel cas tous les anciens enregistrements seront placés à NULL (dans cette colonne j'entends). Après tout dépend des traitements que tu en fais, surtout de tes SELECT. Si tu faisais des SELECT * tu rapporteras une colonne en plus, dans les jointures idem, etc... tu comprends ?

Ce ne sera pas forcément significatif, comme je dis tout dépend de tes requêtes. Mais quoi qu'il en soit, n'hésite pas à ajouter tes colonnes si tu en as besoin bien sûr, c'est fait pour, mais c'est d'un point de vue méthode toujours mieux d'y avoir pensé au début (je pense)

En fait, à priori les requêtes du type SELECT * devraient être très rares, dans cette base ce sera des chiffres de suivi de production indus, et donc les requêtes seront relativement précisent, car se sera surtout pour des sorties du type courbes de tendance, d'évolution, etc...

Je suis d'accord sur le fait qu'il vaut mieux y penser avant, mais sur des applis du style suivi de prod, tôt ou tard, tu as toujours un gus te demandant un truc du genre (citation vécue...) : "C'est super, mais en fait, si l'on suivait ça en plus, ce serait le top, tu peux bien nous rajouter ça, hein ?"

Envoyé par dbprog

Le plus important est de bien choisir le type de données aussi. Des choses bêtes, comme tinyint, mediumint, int, peuvent influer sur la qualité des requêtes et la place prise par ta base, si le volume de données commence à devenir conséquent. Mais autant prendre les bonnes habitudes tout de suite

Pour ça, pas de problème, mais tu as raison de le rappeler !!! J'ai bien sûr prévu pour l'avenir, mais sans mettre du bigint partout !!!
Car même si les disques durs de serveur se compte maintenant en centaine de Go, il faut rester raisonnable...

En tout cas, merci pour ta réponse aussi précise !!

[berceker united]

"100000 enregistrements..." ?
ppff tu le chatouilles le Mysql là

[shkyo]

Envoyé par berceker united

"100000 enregistrements..." ?
ppff tu le chatouilles le Mysql là

Et ben en fait, d'après mes calculs, cela devrait être ça, mais par mois, donc 1200000 par an... c'est mieux ?

Blague à part, juste pour info, avec MySQL on note des ralentissements sur les requêtes basiques (petits SELECT mono ou multitables parfois) à partir de quel volume de données ??

[Maximilian]

Difficile à dire, ça dépend de la structure de la base (notamment si elle a été bien conçue...) et de la puissance du serveur.

[shkyo]

Envoyé par Maximilian

Difficile à dire, ça dépend de la structure de la base (notamment si elle a été bien conçue...) et de la puissance du serveur.

Mouais, d'après ce que je peux lire, par-ci par-là, la BD que je vais développer restera dans la court des petites BD avec ses 100000 enregistrements/mois et ses 150 ou 200 requêtes par jour...

Donc, en théorie, je ne devrais pas être trop inquièté par les perfs sur mon P3 833MHz avec 1.3Go de RAM et RAID5 SCSI, sachant que début 2007 je migre sur du bi-pro XEON 2GHz avec 2Go de RAM toujours en RAID5 SCSI...

Mais bon, tout est relatif (comme dirais l'autre), et j'aime bien me renseigner avant, c'est mieux je trouve, que quand tu es dans la mouise !!!

[Maximilian]

Envoyé par shkyo

Mouais, d'après ce que je peux lire, par-ci par-là, la BD que je vais développer restera dans la court des petites BD avec ses 100000 enregistrements/mois et ses 150 ou 200 requêtes par jour...

Effectivement, c'est une volumétrie plutôt moyenne et la charge est faible (à moins que ça soit des requêtes avec des calculs de malade )

Envoyé par shkyo

Donc, en théorie, je ne devrais pas être trop inquièté par les perfs sur mon P3 833MHz avec 1.3Go de RAM et RAID5 SCSI, sachant que début 2007 je migre sur du bi-pro XEON 2GHz avec 2Go de RAM toujours en RAID5 SCSI...

Si c'est des serveurs dédiés à MySQL no soucy, par contre le premier me parait un peu étroit à moyen terme pour un serveur d'application + SGBD.

[shkyo]

Envoyé par Maximilian

Effectivement, c'est une volumétrie plutôt moyenne et la charge est faible (à moins que ça soit des requêtes avec des calculs de malade )


Si c'est des serveurs dédiés à MySQL no soucy, par contre le premier me parait un peu étroit à moyen terme pour un serveur d'application + SGBD.

C'est vrai qu'il n'est plus tout jeune (7 ans !!) mon IBM, mais justement je le change dans 6 mois, ouf... Un bi-pro ça va mieux respirer !! Sachant que je n'ai qu'une grosse cinquantaine de users qui ne font pas de multimédia mais du Word/Excel "classique", au niveau charge j'ai de la marge !

Mais je n'ai pas de serveurs d'applis, ce n'est que du serveur de données sous Win2003 Server, donc je ne pense pas que MySQL gène beaucoup...
Pour l'instant, dans ma boite, on pratique le client "lourd" (P4 3.2GHz 512Mo RAM) ...

[berceker united]

Sur game boy mysql peut tourner mais vous pouvez le faire ramer avec des requête de "chien malade". Quand je vois se genre de chose. .... Like 'montruc' bon ben là je dis que c'est pas gagné! des select * from et n'avoir besoin que deux champs etc.