de rien.

pense que la limitation en taille c'est la taille disque dont tu dispose ;)

et un modèle bien fait va t'en faire économiser (en évitant les doublons de données par exemple).

si tu veux faire un test télécharge [url=https://dev.mysql.com/doc/employee/en/employees-installation.html]la base exemple de mysql[/url] et la charger tu verra que ton serveur va encaisser le chargement d'une base déjà conséquente (le dump fait 160Mo)

@+

Bonjour,

merci beaucoup pour ta réponse !
C'est vrai que j'avais effectivement lu qu'il valait mieux optimiser ses tables à la fin, mais là je parlais de séparer des tables, c'est la raison pour laquelle je pensais qu'il valait mieux le faire dès le début !

Tu n'as pas tort en ce qui concerne les entrées, c'est vrai que ça peut sembler petit ! Mais si je me posais la question, c'est juste parce que je n'ai pas non plus les mêmes serveurs que ces sites internet :P Mais je conçois qu'effectivement ça reste léger, je n'ai pas bien la notion de la quantité de données possibles à traiter sur mon pauvre Kimsufi :)

Je vais étudier plus en détail le lien que tu m'as fourni !

Merci encore :)

salut,

non.

d'ailleurs, tel que décrit, ton modèle semble foireux.

je peux me tromper mais c'est l'impression que j'ai eu en lisant ton message ;)

[quote="Gaultier"]donc j'essaye de voir pour optimiser dès le début, bien que ça ne soit pas toujours la bonne méthode.[/quote]

toujours meilleurs que le faire a posteriori, sauf bien entendu si tu t'es vautré a l'expression des besoin, cahier des charges etc etc :mrgreen:

[quote="Gaultier"]Le logiciel sera amené à être relativement conséquent par la suite, étant donné que chaque journée, 500-1000 entrées y seront ajoutées,[/quote]
ce n'est un rien un sgbd est prévu pour encaisser bien plus que cela.
A ton avis il y a combien d'entrée / jour dans les bases de facebook ou stackoverflow ? (je ne dit phpfrance on doit être en deça de la fourchette ;) )
1000 entrées/ jour cela fait 1 insertions toutes les 3.6s (en moyenne sur une journée) regarde combien de temps prend une insertion tu verra que tu as de la marge ;)

Donc, une base de donnée, tout comme l'application complète doit être modélisée. C'est primordiale si tu ne veux pas te vautrer.
un mauvais modèle de données, c'est la merde à utiliser, c'est la merde à maintenir etc etc.

Ce qui est fait le plus souvent c'est des lectures et c'est que tu doit optimiser.
Si tu cherche des performances extrêmes il te faudra de l'aide, car cela passe par la configuration du SGBD (cache serveur, cluster etc etc) et ça ne s'invente pas.

je te conseil, [url=http://sqlpro.developpez.com/cours/modelisation/merise/]le modèle entité / association (de la méthode merise)[/url] pour t'aider à construire ton modèle. Ceci t'évitera de partir dans des suppositions.
si ensuite tu veux voir s'il y a des goulets d'étranglement dans les requêtes tu peux utiliser "explain" pour savoir où cela se situe.
Je suis d'accord c'est une phase parfois longue et fastidieuse (comme tout modèle) mais c'est un paris sur l'avenir. (savant que derrière cela aidera les future développeur de l'application si ce n'est pas toi, ou si tu as de l'aide etc etc).

@+

Bonjour,

j'ai commencé le langage MySQL il y a longtemps, et cela fait longtemps que je n'ai pas mis la main à la pâte. Cependant, j'aimerais créer un logiciel de gestion clients / tâches effectuées par les employés pour l'agence [url=http://rankerz.fr]Rankerz[/url].
Le fait est que ce logiciel utilise bien entendu énormément de SQL et de traitement PHP.

Le logiciel sera amené à être relativement conséquent par la suite, étant donné que chaque journée, 500-1000 entrées y seront ajoutées, donc j'essaye de voir pour optimiser dès le début, bien que ça ne soit pas toujours la bonne méthode. Donc voilà, je ne sais pas si c'est réellement la bonne méthode, mais j'ai fait quelques tables qui ne sont composées que d'index et de valeurs binaires (pour sélectionner les lignes qui nous intéressent les plus rapidement), et l'objectif est ensuite de récupérer les données relatives aux identifiants disposés dans une autre table.

Par souci de performance, j'aurais voulu savoir si pour récupérer les informations de ces identifiants, il y avait un réel avantage à faire des jointures ? Ce que je veux dire par là, c'est que je pourrais faire une pseudo-jointure en PHP, à savoir récupérer l'identifiant et effectuer une nouvelle requête SQL à partir de cet identifiant.

C'est pas très clair, donc je vais résumer : le fait de faire une requête dans une requête via MySQL est il plus rapide que de faire une requête à partir du résultat d'une autre requête en PHP ?

En vous remerciant par avance, j'espère que j'aurais été assez clair, mais j'ai du mal à exprimer le problème !