Discussion :

[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 !

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 !

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.

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

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]

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...

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 ?"

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]

"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 ??

[Maximil ian]

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.