Soit une base de données MySQL (4.1.13) avec une structure de données mal
foutue depuis le début et pas restructurable dans l'immédiat.
En gros, on en est à un point ou il faut faire des jointures (en Y)
quasiment à chaque requete, avec des tables relativement déséquilibrées etc
etc.
Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ 20Mo de
données et fichiers en tout genre.
Dans l'état actuel des choses, les requetes (les temps pour les accomplir)
s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
Les accès au disque sont relativement peu nombreux (ça ne métonne pas trop,
vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).
J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le
plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.
Si d'un autre hote je lance la même requete ou une autre tout aussi
prenante, toujours un seul core utilisé pour les deux requetes...
- Comment forcer MySQL à utiliser un max de "Cores" possible?
Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en 5.x) que
la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en
mesure d'utiliser les X Cores pour la multitude de requetes simultannées
qu'il reçoit, ça va pas le faire...
Soit une base de données MySQL (4.1.13) avec une structure de données mal foutue depuis le début et pas restructurable dans l'immédiat. En gros, on en est à un point ou il faut faire des jointures (en Y) quasiment à chaque requete, avec des tables relativement déséquilibrées etc etc.
Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ 20Mo de données et fichiers en tout genre.
Dans l'état actuel des choses, les requetes (les temps pour les accomplir) s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
le malade à de la fièvre : soignons la fièvre...
C'est en général le constat des débutants qui ignorent comment fonctionne un SGBDR...
Les accès au disque sont relativement peu nombreux (ça ne métonne pas trop, vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).
J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.
Cela veut donc dire que les process ne sont pas parrallélisables... Donc non seulement la base est mal structurée mais le stockage des données, l'indexation comme l'écriture des requêtes sont probablement pourries...
Si d'un autre hote je lance la même requete ou une autre tout aussi prenante, toujours un seul core utilisé pour les deux requetes...
- Comment forcer MySQL à utiliser un max de "Cores" possible?
En restructurant votre base, vos espaces de stockage des données, en indexant correctement et en récrivant vos requêtes... etc !
Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en 5.x) que la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en mesure d'utiliser les X Cores pour la multitude de requetes simultannées qu'il reçoit, ça va pas le faire...
Cela n'arrangera rien, bien au contraire. Compte tenu des nouveauté sde la version, le noyau applicatif sera plus lourd, donc moins de cache dispo pour les données.
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Imaginez que vous avez une voiture avec des roues carrées. En augmentant la puissance du moteur cela ira t-il mieux ?
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Bonjour,
Mihamina Rakotomandimby (R12y) a écrit :
Bonjour,
Soit une base de données MySQL (4.1.13) avec une structure de données mal
foutue depuis le début et pas restructurable dans l'immédiat.
En gros, on en est à un point ou il faut faire des jointures (en Y)
quasiment à chaque requete, avec des tables relativement déséquilibrées etc
etc.
Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ 20Mo de
données et fichiers en tout genre.
Dans l'état actuel des choses, les requetes (les temps pour les accomplir)
s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
le malade à de la fièvre : soignons la fièvre...
C'est en général le constat des débutants qui ignorent comment
fonctionne un SGBDR...
Les accès au disque sont relativement peu nombreux (ça ne métonne pas trop,
vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).
J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le
plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.
Cela veut donc dire que les process ne sont pas parrallélisables...
Donc non seulement la base est mal structurée mais le stockage des
données, l'indexation comme l'écriture des requêtes sont probablement
pourries...
Si d'un autre hote je lance la même requete ou une autre tout aussi
prenante, toujours un seul core utilisé pour les deux requetes...
- Comment forcer MySQL à utiliser un max de "Cores" possible?
En restructurant votre base, vos espaces de stockage des données, en
indexant correctement et en récrivant vos requêtes... etc !
Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en 5.x) que
la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en
mesure d'utiliser les X Cores pour la multitude de requetes simultannées
qu'il reçoit, ça va pas le faire...
Cela n'arrangera rien, bien au contraire. Compte tenu des nouveauté sde
la version, le noyau applicatif sera plus lourd, donc moins de cache
dispo pour les données.
50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.
Imaginez que vous avez une voiture avec des roues carrées. En augmentant
la puissance du moteur cela ira t-il mieux ?
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Soit une base de données MySQL (4.1.13) avec une structure de données mal foutue depuis le début et pas restructurable dans l'immédiat. En gros, on en est à un point ou il faut faire des jointures (en Y) quasiment à chaque requete, avec des tables relativement déséquilibrées etc etc.
Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ 20Mo de données et fichiers en tout genre.
Dans l'état actuel des choses, les requetes (les temps pour les accomplir) s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
le malade à de la fièvre : soignons la fièvre...
C'est en général le constat des débutants qui ignorent comment fonctionne un SGBDR...
Les accès au disque sont relativement peu nombreux (ça ne métonne pas trop, vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).
J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.
Cela veut donc dire que les process ne sont pas parrallélisables... Donc non seulement la base est mal structurée mais le stockage des données, l'indexation comme l'écriture des requêtes sont probablement pourries...
Si d'un autre hote je lance la même requete ou une autre tout aussi prenante, toujours un seul core utilisé pour les deux requetes...
- Comment forcer MySQL à utiliser un max de "Cores" possible?
En restructurant votre base, vos espaces de stockage des données, en indexant correctement et en récrivant vos requêtes... etc !
Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en 5.x) que la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en mesure d'utiliser les X Cores pour la multitude de requetes simultannées qu'il reçoit, ça va pas le faire...
Cela n'arrangera rien, bien au contraire. Compte tenu des nouveauté sde la version, le noyau applicatif sera plus lourd, donc moins de cache dispo pour les données.
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Imaginez que vous avez une voiture avec des roues carrées. En augmentant la puissance du moteur cela ira t-il mieux ?
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
nemo
Fred Brouard - SQLpro a écrit :
Bonjour,
Mihamina Rakotomandimby (R12y) a écrit :
Bonjour,
Soit une base de données MySQL (4.1.13) avec une structure de données mal foutue depuis le début et pas restructurable dans l'immédiat. En gros, on en est à un point ou il faut faire des jointures (en Y) quasiment à chaque requete, avec des tables relativement déséquilibrées etc etc.
Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ 20Mo de données et fichiers en tout genre.
Dans l'état actuel des choses, les requetes (les temps pour les accomplir) s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
le malade à de la fièvre : soignons la fièvre...
C'est en général le constat des débutants qui ignorent comment fonctionne un SGBDR...
médicalement c'est la méthode pour soigner un malade (la fièvre soigne le malade et le médecin empêche la fièvre de montée au delà des limites du raisonnable pour que l'excès de fièvre ne tue pas le malade)
Les accès au disque sont relativement peu nombreux (ça ne métonne pas trop, vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).
J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.
Cela veut donc dire que les process ne sont pas parrallélisables... Donc non seulement la base est mal structurée mais le stockage des données, l'indexation comme l'écriture des requêtes sont probablement pourries...
Si d'un autre hote je lance la même requete ou une autre tout aussi prenante, toujours un seul core utilisé pour les deux requetes...
- Comment forcer MySQL à utiliser un max de "Cores" possible?
En restructurant votre base, vos espaces de stockage des données, en indexant correctement et en récrivant vos requêtes... etc !
Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en 5.x) que la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en mesure d'utiliser les X Cores pour la multitude de requetes simultannées qu'il reçoit, ça va pas le faire...
Cela n'arrangera rien, bien au contraire. Compte tenu des nouveauté sde la version, le noyau applicatif sera plus lourd, donc moins de cache dispo pour les données.
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Imaginez que vous avez une voiture avec des roues carrées. En augmentant la puissance du moteur cela ira t-il mieux ?
oui car les roues grâce a la puissance du moteur s'arrondiront au bout de quelques (dizaine ou centaine ) kilomètres
Fred Brouard - SQLpro a écrit :
Bonjour,
Mihamina Rakotomandimby (R12y) a écrit :
Bonjour,
Soit une base de données MySQL (4.1.13) avec une structure de données mal
foutue depuis le début et pas restructurable dans l'immédiat.
En gros, on en est à un point ou il faut faire des jointures (en Y)
quasiment à chaque requete, avec des tables relativement
déséquilibrées etc
etc.
Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ
20Mo de
données et fichiers en tout genre.
Dans l'état actuel des choses, les requetes (les temps pour les
accomplir)
s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
le malade à de la fièvre : soignons la fièvre...
C'est en général le constat des débutants qui ignorent comment
fonctionne un SGBDR...
médicalement c'est la méthode pour soigner un malade
(la fièvre soigne le malade et le médecin empêche la fièvre de montée au
delà des limites du raisonnable pour que l'excès de fièvre ne tue pas le
malade)
Les accès au disque sont relativement peu nombreux (ça ne métonne pas
trop,
vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).
J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le
plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.
Cela veut donc dire que les process ne sont pas parrallélisables...
Donc non seulement la base est mal structurée mais le stockage des
données, l'indexation comme l'écriture des requêtes sont probablement
pourries...
Si d'un autre hote je lance la même requete ou une autre tout aussi
prenante, toujours un seul core utilisé pour les deux requetes...
- Comment forcer MySQL à utiliser un max de "Cores" possible?
En restructurant votre base, vos espaces de stockage des données, en
indexant correctement et en récrivant vos requêtes... etc !
Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en
5.x) que
la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en
mesure d'utiliser les X Cores pour la multitude de requetes simultannées
qu'il reçoit, ça va pas le faire...
Cela n'arrangera rien, bien au contraire. Compte tenu des nouveauté sde
la version, le noyau applicatif sera plus lourd, donc moins de cache
dispo pour les données.
50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.
Imaginez que vous avez une voiture avec des roues carrées. En augmentant
la puissance du moteur cela ira t-il mieux ?
oui car les roues grâce a la puissance du moteur s'arrondiront au bout
de quelques (dizaine ou centaine ) kilomètres
Soit une base de données MySQL (4.1.13) avec une structure de données mal foutue depuis le début et pas restructurable dans l'immédiat. En gros, on en est à un point ou il faut faire des jointures (en Y) quasiment à chaque requete, avec des tables relativement déséquilibrées etc etc.
Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ 20Mo de données et fichiers en tout genre.
Dans l'état actuel des choses, les requetes (les temps pour les accomplir) s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
le malade à de la fièvre : soignons la fièvre...
C'est en général le constat des débutants qui ignorent comment fonctionne un SGBDR...
médicalement c'est la méthode pour soigner un malade (la fièvre soigne le malade et le médecin empêche la fièvre de montée au delà des limites du raisonnable pour que l'excès de fièvre ne tue pas le malade)
Les accès au disque sont relativement peu nombreux (ça ne métonne pas trop, vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).
J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.
Cela veut donc dire que les process ne sont pas parrallélisables... Donc non seulement la base est mal structurée mais le stockage des données, l'indexation comme l'écriture des requêtes sont probablement pourries...
Si d'un autre hote je lance la même requete ou une autre tout aussi prenante, toujours un seul core utilisé pour les deux requetes...
- Comment forcer MySQL à utiliser un max de "Cores" possible?
En restructurant votre base, vos espaces de stockage des données, en indexant correctement et en récrivant vos requêtes... etc !
Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en 5.x) que la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en mesure d'utiliser les X Cores pour la multitude de requetes simultannées qu'il reçoit, ça va pas le faire...
Cela n'arrangera rien, bien au contraire. Compte tenu des nouveauté sde la version, le noyau applicatif sera plus lourd, donc moins de cache dispo pour les données.
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Imaginez que vous avez une voiture avec des roues carrées. En augmentant la puissance du moteur cela ira t-il mieux ?
oui car les roues grâce a la puissance du moteur s'arrondiront au bout de quelques (dizaine ou centaine ) kilomètres
Lionel
Mihamina Rakotomandimby (R12y) wrote:
Dans l'état actuel des choses, les requetes (les temps pour les accomplir) s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
Il faudrait plutot diminuer la conso de CPU, non ?
Regarde le plan d'execution des requetes, peut etre que ca te permettra de les optimiser.
Mihamina Rakotomandimby (R12y) wrote:
Dans l'état actuel des choses, les requetes (les temps pour les
accomplir) s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
Il faudrait plutot diminuer la conso de CPU, non ?
Regarde le plan d'execution des requetes, peut etre que ca te permettra de
les optimiser.
Dans l'état actuel des choses, les requetes (les temps pour les accomplir) s'allongent.
On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
Il faudrait plutot diminuer la conso de CPU, non ?
Regarde le plan d'execution des requetes, peut etre que ca te permettra de les optimiser.
Chris
Fred Brouard - SQLpro a écrit :
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un graphique issue d'un paragraphe d'optimisation de base Oracle qui stipule que :
En général les problèmes de performance :
5% proviennent de l'OS 15% proviennent du paramétrage de la base 25% proviennent de la conception de la base le reste soit 55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe quel base
A+ chris
Fred Brouard - SQLpro a écrit :
50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un
graphique issue d'un paragraphe d'optimisation de base Oracle qui
stipule que :
En général les problèmes de performance :
5% proviennent de l'OS
15% proviennent du paramétrage de la base
25% proviennent de la conception de la base
le reste soit
55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe
quel base
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un graphique issue d'un paragraphe d'optimisation de base Oracle qui stipule que :
En général les problèmes de performance :
5% proviennent de l'OS 15% proviennent du paramétrage de la base 25% proviennent de la conception de la base le reste soit 55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe quel base
A+ chris
Fred Brouard - SQLpro
Chris a écrit :
Fred Brouard - SQLpro a écrit :
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un graphique issue d'un paragraphe d'optimisation de base Oracle qui stipule que :
En général les problèmes de performance :
5% proviennent de l'OS 15% proviennent du paramétrage de la base 25% proviennent de la conception de la base le reste soit 55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe quel base
A+ chris
mon expérience me montre le contraire : 5% proviennent de l'OS OK 15% proviennent du paramétrage de la base OK 25% proviennent de la conception de la base NON ! 55% proviennent de la programmation NON !
cela était valable du temps du cobol, mais plus maintenant avec les procédures stockées, les middleware et le reste... La tendance s'est notablement inversée depuis maintenant bien une décennie...
donc : 25 % de la programmation 55% du modèle de données.
Il n'y a qu'à voir les maigres cours sur le conception des BD dans les écoles d'ingé et les cours universitaires.
par exemple je dois faire en 32 heures de cours : - historique - df - algègre relationnelle - formes normales (de 1 à 5) - méthodes d'analyse (ascendante/descendante) - mcd (merise, IDF1X, E/R, UML2) - mld/mpd - études de cas - qualité des données - conceptions de data warahouse ...
et je constate au quotiden dans les audit la pauvrété du MR : pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de normalisation.
Lisez la discussions que nous avons eu à ce sujet sur htt://www.developpez.com : http://www.developpez.net/forums/showthread.php?tb31
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Chris a écrit :
Fred Brouard - SQLpro a écrit :
50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un
graphique issue d'un paragraphe d'optimisation de base Oracle qui
stipule que :
En général les problèmes de performance :
5% proviennent de l'OS
15% proviennent du paramétrage de la base
25% proviennent de la conception de la base
le reste soit
55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe
quel base
A+
chris
mon expérience me montre le contraire :
5% proviennent de l'OS OK
15% proviennent du paramétrage de la base OK
25% proviennent de la conception de la base NON !
55% proviennent de la programmation NON !
cela était valable du temps du cobol, mais plus maintenant avec les
procédures stockées, les middleware et le reste...
La tendance s'est notablement inversée depuis maintenant bien une
décennie...
donc :
25 % de la programmation
55% du modèle de données.
Il n'y a qu'à voir les maigres cours sur le conception des BD dans les
écoles d'ingé et les cours universitaires.
par exemple je dois faire en 32 heures de cours :
- historique
- df
- algègre relationnelle
- formes normales (de 1 à 5)
- méthodes d'analyse (ascendante/descendante)
- mcd (merise, IDF1X, E/R, UML2)
- mld/mpd
- études de cas
- qualité des données
- conceptions de data warahouse
...
et je constate au quotiden dans les audit la pauvrété du MR :
pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de
normalisation.
Lisez la discussions que nous avons eu à ce sujet sur
htt://www.developpez.com :
http://www.developpez.net/forums/showthread.php?tb31
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un graphique issue d'un paragraphe d'optimisation de base Oracle qui stipule que :
En général les problèmes de performance :
5% proviennent de l'OS 15% proviennent du paramétrage de la base 25% proviennent de la conception de la base le reste soit 55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe quel base
A+ chris
mon expérience me montre le contraire : 5% proviennent de l'OS OK 15% proviennent du paramétrage de la base OK 25% proviennent de la conception de la base NON ! 55% proviennent de la programmation NON !
cela était valable du temps du cobol, mais plus maintenant avec les procédures stockées, les middleware et le reste... La tendance s'est notablement inversée depuis maintenant bien une décennie...
donc : 25 % de la programmation 55% du modèle de données.
Il n'y a qu'à voir les maigres cours sur le conception des BD dans les écoles d'ingé et les cours universitaires.
par exemple je dois faire en 32 heures de cours : - historique - df - algègre relationnelle - formes normales (de 1 à 5) - méthodes d'analyse (ascendante/descendante) - mcd (merise, IDF1X, E/R, UML2) - mld/mpd - études de cas - qualité des données - conceptions de data warahouse ...
et je constate au quotiden dans les audit la pauvrété du MR : pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de normalisation.
Lisez la discussions que nous avons eu à ce sujet sur htt://www.developpez.com : http://www.developpez.net/forums/showthread.php?tb31
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
nemo
Fred Brouard - SQLpro a écrit :
Chris a écrit :
Fred Brouard - SQLpro a écrit :
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un graphique issue d'un paragraphe d'optimisation de base Oracle qui stipule que :
En général les problèmes de performance :
5% proviennent de l'OS 15% proviennent du paramétrage de la base 25% proviennent de la conception de la base le reste soit 55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe quel base
A+ chris
mon expérience me montre le contraire : 5% proviennent de l'OS OK 15% proviennent du paramétrage de la base OK 25% proviennent de la conception de la base NON ! 55% proviennent de la programmation NON !
cela était valable du temps du cobol, mais plus maintenant avec les procédures stockées, les middleware et le reste... La tendance s'est notablement inversée depuis maintenant bien une décennie...
donc : 25 % de la programmation 55% du modèle de données.
Il n'y a qu'à voir les maigres cours sur le conception des BD dans les écoles d'ingé et les cours universitaires.
par exemple je dois faire en 32 heures de cours : - historique - df - algègre relationnelle - formes normales (de 1 à 5) - méthodes d'analyse (ascendante/descendante) - mcd (merise, IDF1X, E/R, UML2) - mld/mpd - études de cas - qualité des données - conceptions de data warahouse ...
et je constate au quotiden dans les audit la pauvrété du MR : pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur htt://www.developpez.com : http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré les responsables de celui ci et nous avons la même opinion négative sur le dénommé Fred Brouard.
Fred Brouard - SQLpro a écrit :
Chris a écrit :
Fred Brouard - SQLpro a écrit :
50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un
graphique issue d'un paragraphe d'optimisation de base Oracle qui
stipule que :
En général les problèmes de performance :
5% proviennent de l'OS
15% proviennent du paramétrage de la base
25% proviennent de la conception de la base
le reste soit
55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe
quel base
A+
chris
mon expérience me montre le contraire :
5% proviennent de l'OS OK
15% proviennent du paramétrage de la base OK
25% proviennent de la conception de la base NON !
55% proviennent de la programmation NON !
cela était valable du temps du cobol, mais plus maintenant avec les
procédures stockées, les middleware et le reste...
La tendance s'est notablement inversée depuis maintenant bien une
décennie...
donc :
25 % de la programmation
55% du modèle de données.
Il n'y a qu'à voir les maigres cours sur le conception des BD dans les
écoles d'ingé et les cours universitaires.
par exemple je dois faire en 32 heures de cours :
- historique
- df
- algègre relationnelle
- formes normales (de 1 à 5)
- méthodes d'analyse (ascendante/descendante)
- mcd (merise, IDF1X, E/R, UML2)
- mld/mpd
- études de cas
- qualité des données
- conceptions de data warahouse
...
et je constate au quotiden dans les audit la pauvrété du MR :
pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de
normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont
indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur
htt://www.developpez.com :
http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré
les responsables de celui ci et nous avons la même opinion négative sur
le dénommé Fred Brouard.
50 à 70 % des problèmes de performances viennent du modèle de données. il n'est pas possible d'un coup de baguette magique de remplacer les défaut d'un modèle merdique par un astuce technique.
Bonjour,
je me permets de mettre mon grain de sel dans ce thread car j'ai un graphique issue d'un paragraphe d'optimisation de base Oracle qui stipule que :
En général les problèmes de performance :
5% proviennent de l'OS 15% proviennent du paramétrage de la base 25% proviennent de la conception de la base le reste soit 55% proviennent de la programmation
On pourrait moduler mais en gros cela doit être valable pour n'importe quel base
A+ chris
mon expérience me montre le contraire : 5% proviennent de l'OS OK 15% proviennent du paramétrage de la base OK 25% proviennent de la conception de la base NON ! 55% proviennent de la programmation NON !
cela était valable du temps du cobol, mais plus maintenant avec les procédures stockées, les middleware et le reste... La tendance s'est notablement inversée depuis maintenant bien une décennie...
donc : 25 % de la programmation 55% du modèle de données.
Il n'y a qu'à voir les maigres cours sur le conception des BD dans les écoles d'ingé et les cours universitaires.
par exemple je dois faire en 32 heures de cours : - historique - df - algègre relationnelle - formes normales (de 1 à 5) - méthodes d'analyse (ascendante/descendante) - mcd (merise, IDF1X, E/R, UML2) - mld/mpd - études de cas - qualité des données - conceptions de data warahouse ...
et je constate au quotiden dans les audit la pauvrété du MR : pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur htt://www.developpez.com : http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré les responsables de celui ci et nous avons la même opinion négative sur le dénommé Fred Brouard.
nemo
Mihamina (R12y) Rakotomandimby a écrit :
nemo - <46684629$0$22483$ :
et je constate au quotiden dans les audit la pauvrété du MR : pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur htt://www.developpez.com : http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré les responsables de celui ci et nous avons la même opinion négative sur le dénommé Fred Brouard.
Techniquement ou personnellement (relationele)? Je dis ça parceque la plupart des gens techniquement ters fort que j'ai rencontré sont tres difficiles à vivre...
une synthèse de la conversation "Que pensez vous de Fred Brouard?" est entre autre :
techniquement des lacunes et relationnelle perturbé par des traits de monomanies tel "access c'est de la merde"
Mihamina (R12y) Rakotomandimby a écrit :
nemo - <46684629$0$22483$426a74cc@news.free.fr> :
et je constate au quotiden dans les audit la pauvrété du MR :
pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de
normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont
indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur
htt://www.developpez.com :
http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré
les responsables de celui ci et nous avons la même opinion négative sur
le dénommé Fred Brouard.
Techniquement ou personnellement (relationele)?
Je dis ça parceque la plupart des gens techniquement ters fort que j'ai
rencontré sont tres difficiles à vivre...
une synthèse de la conversation "Que pensez vous de Fred Brouard?" est
entre autre :
techniquement des lacunes et relationnelle perturbé par des traits de
monomanies tel "access c'est de la merde"
et je constate au quotiden dans les audit la pauvrété du MR : pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur htt://www.developpez.com : http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré les responsables de celui ci et nous avons la même opinion négative sur le dénommé Fred Brouard.
Techniquement ou personnellement (relationele)? Je dis ça parceque la plupart des gens techniquement ters fort que j'ai rencontré sont tres difficiles à vivre...
une synthèse de la conversation "Que pensez vous de Fred Brouard?" est entre autre :
techniquement des lacunes et relationnelle perturbé par des traits de monomanies tel "access c'est de la merde"
Mihamina (R12y) Rakotomandimby
nemo - <46684629$0$22483$ :
et je constate au quotiden dans les audit la pauvrété du MR : pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur htt://www.developpez.com : http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré les responsables de celui ci et nous avons la même opinion négative sur le dénommé Fred Brouard.
Techniquement ou personnellement (relationele)? Je dis ça parceque la plupart des gens techniquement ters fort que j'ai rencontré sont tres difficiles à vivre...
nemo - <46684629$0$22483$426a74cc@news.free.fr> :
et je constate au quotiden dans les audit la pauvrété du MR :
pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de
normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont
indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur
htt://www.developpez.com :
http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré
les responsables de celui ci et nous avons la même opinion négative sur
le dénommé Fred Brouard.
Techniquement ou personnellement (relationele)?
Je dis ça parceque la plupart des gens techniquement ters fort que j'ai
rencontré sont tres difficiles à vivre...
et je constate au quotiden dans les audit la pauvrété du MR : pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de normalisation.
Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur htt://www.developpez.com : http://www.developpez.net/forums/showthread.php?tb31
Amusante la référence au site ci dessus car au linux expo j'ai rencontré les responsables de celui ci et nous avons la même opinion négative sur le dénommé Fred Brouard.
Techniquement ou personnellement (relationele)? Je dis ça parceque la plupart des gens techniquement ters fort que j'ai rencontré sont tres difficiles à vivre...
