29-03-2017, 10:19 AM
Je pense que Metallique a déjà pas mal d'infos pour avancer donc je ne vais pas m'étendre sur le sujet mais il y a quand même un point qui me gène :
Ce n'est pas une information arbitraire. C'est vrai, c'est arrondi car je n'ai pas déterminé la valeur exacte qui doit être plus proche de 8000 pour une conf standard (et ça dépend aussi du nombre de champs, bien sûr). Et si tu ne veux pas t'amuser à faire du tuning MySQL c'est ce genre de limites auxquelles j'ai toujours été confronté et ça fait 13 ans que je fais du MySQL.
Évidemment j'ai eu des cas où je pouvais charger par paquets de 50 000 mais ça nécessite de savoir paramétrer un serveur MySQL (et d'avoir accès à la conf) et tu n'a qu'un gain de x10 par rapport à des blocs de 5 000 (valeur que je j'utilise en général) qui est déjà une bonne optimisation par rapport à des INSERT unitaires. De toutes façons tu ne peux pas te permettre de ne pas connaitre la taille des blocs que tu insères si ton volume est trop variable (un jour tu te réveilles ton serveur est planté car tu as doublé la taille et hop, ça ne passe plus en RAM). Rien n'empêche de mettre le nombre de lignes en paramètre et l'augmenter par la suite quand ça s'avèrera indispensable.
Et puis bon le terme "contrer", ça sonne un peu bizarre dans ce contexte.
A titre d'info pour avoir également bossé avec Oracle, MariaDB et Postgres :
- Oracle : il est plus robuste et plus complets en terme de fonctionnalités. J'ai bossé 5 ans dessus et je n'en ai pas fait le tour, le coût pour un particulier doit être costaud (mais je n'ai pas vérifié)
- MariaDB : je n'ai pas remarqué de différence notable avec MySQL au niveau technique, je pense que la différence est surtout dans la licence (voir Wikipédia)
- Postgres : je le vois comme un mix en MySQL et Oracle. Il a plus de fonctionnalité que MySQL mais n'a pas la robustesse d'Oracle. Je le trouvais pas mal quand il n'y avait pas de triggers/procédures stockées en MySQL.
(28-03-2017, 06:35 PM)Xenos a écrit : C'est surtout l'affirmation arbitraire de "10000 lignes" que je voulais contrer.
Ce n'est pas une information arbitraire. C'est vrai, c'est arrondi car je n'ai pas déterminé la valeur exacte qui doit être plus proche de 8000 pour une conf standard (et ça dépend aussi du nombre de champs, bien sûr). Et si tu ne veux pas t'amuser à faire du tuning MySQL c'est ce genre de limites auxquelles j'ai toujours été confronté et ça fait 13 ans que je fais du MySQL.
Évidemment j'ai eu des cas où je pouvais charger par paquets de 50 000 mais ça nécessite de savoir paramétrer un serveur MySQL (et d'avoir accès à la conf) et tu n'a qu'un gain de x10 par rapport à des blocs de 5 000 (valeur que je j'utilise en général) qui est déjà une bonne optimisation par rapport à des INSERT unitaires. De toutes façons tu ne peux pas te permettre de ne pas connaitre la taille des blocs que tu insères si ton volume est trop variable (un jour tu te réveilles ton serveur est planté car tu as doublé la taille et hop, ça ne passe plus en RAM). Rien n'empêche de mettre le nombre de lignes en paramètre et l'augmenter par la suite quand ça s'avèrera indispensable.
Et puis bon le terme "contrer", ça sonne un peu bizarre dans ce contexte.
A titre d'info pour avoir également bossé avec Oracle, MariaDB et Postgres :
- Oracle : il est plus robuste et plus complets en terme de fonctionnalités. J'ai bossé 5 ans dessus et je n'en ai pas fait le tour, le coût pour un particulier doit être costaud (mais je n'ai pas vérifié)
- MariaDB : je n'ai pas remarqué de différence notable avec MySQL au niveau technique, je pense que la différence est surtout dans la licence (voir Wikipédia)
- Postgres : je le vois comme un mix en MySQL et Oracle. Il a plus de fonctionnalité que MySQL mais n'a pas la robustesse d'Oracle. Je le trouvais pas mal quand il n'y avait pas de triggers/procédures stockées en MySQL.
Keltaïnen