Je serais intéressé par un exemple, là comme ça je ne vois pas…
Bien essayé, mais pas tant que je n'ai pas fini et publié mon projet.
C'est pourtant relativement simple: ce que tu faisais dans php tu le fais
maintenant dans la PS, avec juste qq lignes de plus pour gérer ce type
d'indirection.
Là aussi, je bloque…
Les données sont totalement inaccessibles de l'extérieur sauf pour le SU de la
DB; seules les PS y ont accès, après contrôle des droits de l'appelant.
Non, le travail est égal, à moins bien sûr que tu n'utilise des trucs de
débutants comme SELECT * FROM matable au lieu de SELECT col1,col2,col6 FROM
matable.
Par exemple avec l'exemple des topics précédents, le fait de rajouter
une date de publication à un post par exemple, nécessite a minima
d'ajouter encore X stored-procs pour pouvoir gérer les filtres et les
tris sur cette colonne, de refondre Y stored-procs pour ajouter cette
date en données de sortie, etc.
Pas plus que dans du code extérieur.
Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
cahier des charges exhaustif
- ET avant tout se rappeler qu'un pro a le DEVOIR
(juridique!) de dire non à son client si ses desiderati sont farfelus.
J'ai souvenir d'un ami a qui le commercial a refilé un dossier; après (courte)
analyse ce que voulait principalement le client se résumait à 30,000 hits à la
seconde...
Ca m'a pris un temps fou en travail et réflexion pour trouver des solutions;
donc comme dit plus haut, pas de comm tant que mon projet n'est pas
terminé/publié (ce qui prendra le même temps... que le fût du canon pour
refroidir:).
Explique-moi la diff que tu vois entre entre des morceaux de php et
différentes PS?
Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a ce rôle).
Par ailleurs je reste persuadé que l'archi 3-tiers est très loin d'être une
panacée universelle; contrairement à ce que pense notamment la plupart des
programmeurs, notamment web.
Le 3-tiers est utile dans certains types d'applis bien particulières, pas dans
toutes.
C'est comme pour les sites qui mettent 3' à charger la page de garde, ça n'est
pas parce qu'on a un quadri-CPU en dev qu'on ne doit pas penser à ceux qui
surfent avec un P3-500 - beaucoup, si ce n'est la plupart, devraient bien se
rentrer cela dans la tête.
Evidemment, cela va à l'encontre de la mode actuelle où il faut pisser de la
ligne de code au kilomètre et où bien souvent on ne se pose la bonne question
que trop tard.
Je serais intéressé par un exemple, là comme ça je ne vois pas…
Bien essayé, mais pas tant que je n'ai pas fini et publié mon projet.
C'est pourtant relativement simple: ce que tu faisais dans php tu le fais
maintenant dans la PS, avec juste qq lignes de plus pour gérer ce type
d'indirection.
Là aussi, je bloque…
Les données sont totalement inaccessibles de l'extérieur sauf pour le SU de la
DB; seules les PS y ont accès, après contrôle des droits de l'appelant.
Non, le travail est égal, à moins bien sûr que tu n'utilise des trucs de
débutants comme SELECT * FROM matable au lieu de SELECT col1,col2,col6 FROM
matable.
Par exemple avec l'exemple des topics précédents, le fait de rajouter
une date de publication à un post par exemple, nécessite a minima
d'ajouter encore X stored-procs pour pouvoir gérer les filtres et les
tris sur cette colonne, de refondre Y stored-procs pour ajouter cette
date en données de sortie, etc.
Pas plus que dans du code extérieur.
Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
cahier des charges exhaustif
- ET avant tout se rappeler qu'un pro a le DEVOIR
(juridique!) de dire non à son client si ses desiderati sont farfelus.
J'ai souvenir d'un ami a qui le commercial a refilé un dossier; après (courte)
analyse ce que voulait principalement le client se résumait à 30,000 hits à la
seconde...
Ca m'a pris un temps fou en travail et réflexion pour trouver des solutions;
donc comme dit plus haut, pas de comm tant que mon projet n'est pas
terminé/publié (ce qui prendra le même temps... que le fût du canon pour
refroidir:).
Explique-moi la diff que tu vois entre entre des morceaux de php et
différentes PS?
Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a ce rôle).
Par ailleurs je reste persuadé que l'archi 3-tiers est très loin d'être une
panacée universelle; contrairement à ce que pense notamment la plupart des
programmeurs, notamment web.
Le 3-tiers est utile dans certains types d'applis bien particulières, pas dans
toutes.
C'est comme pour les sites qui mettent 3' à charger la page de garde, ça n'est
pas parce qu'on a un quadri-CPU en dev qu'on ne doit pas penser à ceux qui
surfent avec un P3-500 - beaucoup, si ce n'est la plupart, devraient bien se
rentrer cela dans la tête.
Evidemment, cela va à l'encontre de la mode actuelle où il faut pisser de la
ligne de code au kilomètre et où bien souvent on ne se pose la bonne question
que trop tard.
Je serais intéressé par un exemple, là comme ça je ne vois pas…
Bien essayé, mais pas tant que je n'ai pas fini et publié mon projet.
C'est pourtant relativement simple: ce que tu faisais dans php tu le fais
maintenant dans la PS, avec juste qq lignes de plus pour gérer ce type
d'indirection.
Là aussi, je bloque…
Les données sont totalement inaccessibles de l'extérieur sauf pour le SU de la
DB; seules les PS y ont accès, après contrôle des droits de l'appelant.
Non, le travail est égal, à moins bien sûr que tu n'utilise des trucs de
débutants comme SELECT * FROM matable au lieu de SELECT col1,col2,col6 FROM
matable.
Par exemple avec l'exemple des topics précédents, le fait de rajouter
une date de publication à un post par exemple, nécessite a minima
d'ajouter encore X stored-procs pour pouvoir gérer les filtres et les
tris sur cette colonne, de refondre Y stored-procs pour ajouter cette
date en données de sortie, etc.
Pas plus que dans du code extérieur.
Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
cahier des charges exhaustif
- ET avant tout se rappeler qu'un pro a le DEVOIR
(juridique!) de dire non à son client si ses desiderati sont farfelus.
J'ai souvenir d'un ami a qui le commercial a refilé un dossier; après (courte)
analyse ce que voulait principalement le client se résumait à 30,000 hits à la
seconde...
Ca m'a pris un temps fou en travail et réflexion pour trouver des solutions;
donc comme dit plus haut, pas de comm tant que mon projet n'est pas
terminé/publié (ce qui prendra le même temps... que le fût du canon pour
refroidir:).
Explique-moi la diff que tu vois entre entre des morceaux de php et
différentes PS?
Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a ce rôle).
Par ailleurs je reste persuadé que l'archi 3-tiers est très loin d'être une
panacée universelle; contrairement à ce que pense notamment la plupart des
programmeurs, notamment web.
Le 3-tiers est utile dans certains types d'applis bien particulières, pas dans
toutes.
C'est comme pour les sites qui mettent 3' à charger la page de garde, ça n'est
pas parce qu'on a un quadri-CPU en dev qu'on ne doit pas penser à ceux qui
surfent avec un P3-500 - beaucoup, si ce n'est la plupart, devraient bien se
rentrer cela dans la tête.
Evidemment, cela va à l'encontre de la mode actuelle où il faut pisser de la
ligne de code au kilomètre et où bien souvent on ne se pose la bonne question
que trop tard.
Bonjour,
Je viens de me faire pirater ma base de données MYSQL.
apache 2.2.19-2
mysql-server 5.1.58-1
Le petit plaisantin, qui m'a envoyé un mail pour m'avertir de son
« exploit » utilise win NT 5 avec HAVIJ v1.15.
Il a récupéré toute la base : Identifiant et mdp.
Du coût je n'ose plus redémarrer mon serveur.
Une idée de la parade ?
--
Frédéric
F1sxo
Bonjour,
Je viens de me faire pirater ma base de données MYSQL.
apache 2.2.19-2
mysql-server 5.1.58-1
Le petit plaisantin, qui m'a envoyé un mail pour m'avertir de son
« exploit » utilise win NT 5 avec HAVIJ v1.15.
Il a récupéré toute la base : Identifiant et mdp.
Du coût je n'ose plus redémarrer mon serveur.
Une idée de la parade ?
--
Frédéric
F1sxo
Bonjour,
Je viens de me faire pirater ma base de données MYSQL.
apache 2.2.19-2
mysql-server 5.1.58-1
Le petit plaisantin, qui m'a envoyé un mail pour m'avertir de son
« exploit » utilise win NT 5 avec HAVIJ v1.15.
Il a récupéré toute la base : Identifiant et mdp.
Du coût je n'ose plus redémarrer mon serveur.
Une idée de la parade ?
--
Frédéric
F1sxo
Pour moi, une PS, c'est ni plus ni moins que du SQL enrobé dans une méthode.
Si on commence à y intégrer du code métier, j'ai l'impress ion qu'on
s'éloigne très fortement de l'objectif des PS.
Oui, ça d'accord, mais les PS sont quand même ultra-limité esâ¦
Elles ne supportent pas les arguments optionnels par exemple.
Comme je te l'ai mentionné, je ne vois pas comment on peut, via du P S,
arriver à faire ce genre de trucs (pseudo-code, et non sécurita ire je le
précise avant que ça n'hurle ^_^) :
function getTopics ( string[] sortOrders ) {
return "SELECT * FROM topics ORDER BY " + sortOrders.join(",");
}
Le fait d'avoir une requête SQL « dynamique » est pour moi en totale
contradiction avec le fonctionnement même des SP. Ou en tout cas, je ne
vois pas d'autres solutions que de faire :
function getTopics ( string[] sortOrders ) {
if sortOrders.is("date", "author")
return callSPGetTopicsOrderByDateAndAuthor()
else if sortOrders.is("date")
return callSPGetTopicsOrderByDate()
else if sortOrders.is("author")
return callSPGetTopicsOrderByAuthor()
else
return callSPGetTopics()
}
On voit bien l'explosion exponentielle du nombre de SPâ¦
La seule solution que je puisse entrevoir serait de faire :
function getTopics ( string[] sortOrders ) {
return callSPGetTopicsGeneric(sortOrders)
}
ce qui reviendrait à faire descendre les contrôles de sécu rité à la SP
au lieu du PHP, et en plus je n'ose trop imaginer la tronche finale de
la SP qui doit traiter TOUS les cas de requétage de l'application
(ordres de tri, colonnes remontées, jointures possibles (bonjour la
gestion de la sécurité avec les alias qui en découlent⠦), critères de
sélectionsâ¦).
Certes, le « SELECT * » n'est pas recommandé. Mais il a l' avantage de
permettre d'être justement indépendant des SDD derrière : si je modifie
ma table source, je n'ai pas à modifier ma requète !
Le fait de limiter la clause SELECT :
â bride l'application pour toute évolution future
â demande X requètes/SP si j'ai la même « requà ªte »-métier mais avec
dans chaque cas un besoin de colonnes de sortie différent
Il est plus facile de modifier un fichier de mapping de l'ORM / modifier
ma classe de DAO / grepper dans mes fichiers PHP (dans l'ordre de
préférence) que de grepper dans une foultitude de SP.
Surtout que supprimer un champ dans une SP, ça va encore, « gre p » le
verra. Mais difficile de grepper un champ qui n'existe pas encore parce
qu'on veut l'ajouter.
Et quid de la difficulté de s'assurer que les SP du serveur sont bien
celles attendues pour la version X, et pas celles de la version X-N ?
> Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
> cahier des charges exhaustif
Le cahier des charges était exhaustif pour chaque version.
On parle bien d'évolutions plusieurs mois après la mise en prod uction.
Dans mon cas, il s'agissait d'un système de gestion de transactions
bancaires et l'évolution consistait à ajouter de nouveaux crit ères de
calcul (en gros des champs dans les tables, et là on a pleuré d e ne pas
avoir mis de « SELECT * »â¦)
> - ET avant tout se rappeler qu'un pro a le DEVOIR
> (juridique!) de dire non à son client si ses desiderati sont farfe lus.
à l'instant T0 de la signature du contrat, ils n'étaient pas fa rfelus.
à l'instant T0+18mois et 500 SP plus tard, ça l'est devenu un p eu plusâ¦
> J'ai souvenir d'un ami a qui le commercial a refilé un dossier; ap rès
> (courte) analyse ce que voulait principalement le client se résuma it Ã
> 30,000 hits à la seconde...
Cas classique, mais à la réponse à un appel d'offre et ava nt la
signature du contrat, il est souvent difficile de voir tous les futurs
points de blocage, d'autant plus que le client se gardera bien de te
signaler ceux qu'il a déjà anticipés,
et que toi tu es pressé par les délais (4 jours pour répon dre à un appel
d'offre de 1.000 pages).
> Explique-moi la diff que tu vois entre entre des morceaux de php et
> différentes PS?
Physiquement parlant, il n'y en a aucune, tout n'est que fichiers au fina l.
« Métièrement » parlant, un monde sépare les 2, d'autant plus si on sort
du monde PHP.
Je peux par exemple m'appuyer sur la POO (héritage, polymorphisme,
généricité, abstractionâ¦) pour limiter la duplicat ion, centraliser
l'information, factoriser mon codeâ¦
Un exemple à la con : il y a de fortes chances pour que le nom de mes
tables se trouvent à un seul endroit dans mon code, quand chaque SP
devra dupliquer l'information. Idem si j'ai 2 requêtes « identi ques mais
pas tout à fait », fortes chances d'arriver à factoriser t out ça au
niveau code quand les SP feront un gros copié/collé de derrià ¨re les fagots.
> Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a c e rôle).
J'ai toujours du mal à voir comment.
Le but du MVC est d'obtenir une page quasi-HTML (ie. débarrasée de toute
présence de code métier) d'un côté et toute la rà ©cupération des données
de l'autre, de séparer la forme et le contenu en somme.
SP ou pas, ça n'a pas de rapport, ça ne reste que la partie M d u MVC
(qui est ma DAO en JEE par exemple), il te manque encore toute la partie
C et V
> Par ailleurs je reste persuadé que l'archi 3-tiers est très l oin d'être une
> panacée universelle; contrairement à ce que pense notamment l a plupart des
> programmeurs, notamment web.
> Le 3-tiers est utile dans certains types d'applis bien particulièr es, pas
> dans toutes.
Ãa se prête généralement pas trop mal à tout typ e d'application.
Le gros avantage du N-tiers est de permettre des évolutions (mé tier,
physique ou technique) très faciles.
Je change de moteur de base sans rien faire. Je remplace ma DAO JPA par
une couche web-service ou tes SP en 10min. Je scallabilise ma couche
service en 30 min.
> C'est comme pour les sites qui mettent 3' à charger la page de gar de, ça
> n'est pas parce qu'on a un quadri-CPU en dev qu'on ne doit pas penser Ã
> ceux qui surfent avec un P3-500 - beaucoup, si ce n'est la plupart,
> devraient bien se rentrer cela dans la tête.
Certes, mais en même temps, quand tu tapes dans une table de 2To, pas
sûr que le temps de chargement du navigateur soit celui à prend re en
compte =)
Pour moi, une PS, c'est ni plus ni moins que du SQL enrobé dans une méthode.
Si on commence à y intégrer du code métier, j'ai l'impress ion qu'on
s'éloigne très fortement de l'objectif des PS.
Oui, ça d'accord, mais les PS sont quand même ultra-limité esâ¦
Elles ne supportent pas les arguments optionnels par exemple.
Comme je te l'ai mentionné, je ne vois pas comment on peut, via du P S,
arriver à faire ce genre de trucs (pseudo-code, et non sécurita ire je le
précise avant que ça n'hurle ^_^) :
function getTopics ( string[] sortOrders ) {
return "SELECT * FROM topics ORDER BY " + sortOrders.join(",");
}
Le fait d'avoir une requête SQL « dynamique » est pour moi en totale
contradiction avec le fonctionnement même des SP. Ou en tout cas, je ne
vois pas d'autres solutions que de faire :
function getTopics ( string[] sortOrders ) {
if sortOrders.is("date", "author")
return callSPGetTopicsOrderByDateAndAuthor()
else if sortOrders.is("date")
return callSPGetTopicsOrderByDate()
else if sortOrders.is("author")
return callSPGetTopicsOrderByAuthor()
else
return callSPGetTopics()
}
On voit bien l'explosion exponentielle du nombre de SPâ¦
La seule solution que je puisse entrevoir serait de faire :
function getTopics ( string[] sortOrders ) {
return callSPGetTopicsGeneric(sortOrders)
}
ce qui reviendrait à faire descendre les contrôles de sécu rité à la SP
au lieu du PHP, et en plus je n'ose trop imaginer la tronche finale de
la SP qui doit traiter TOUS les cas de requétage de l'application
(ordres de tri, colonnes remontées, jointures possibles (bonjour la
gestion de la sécurité avec les alias qui en découlent⠦), critères de
sélectionsâ¦).
Certes, le « SELECT * » n'est pas recommandé. Mais il a l' avantage de
permettre d'être justement indépendant des SDD derrière : si je modifie
ma table source, je n'ai pas à modifier ma requète !
Le fait de limiter la clause SELECT :
â bride l'application pour toute évolution future
â demande X requètes/SP si j'ai la même « requà ªte »-métier mais avec
dans chaque cas un besoin de colonnes de sortie différent
Il est plus facile de modifier un fichier de mapping de l'ORM / modifier
ma classe de DAO / grepper dans mes fichiers PHP (dans l'ordre de
préférence) que de grepper dans une foultitude de SP.
Surtout que supprimer un champ dans une SP, ça va encore, « gre p » le
verra. Mais difficile de grepper un champ qui n'existe pas encore parce
qu'on veut l'ajouter.
Et quid de la difficulté de s'assurer que les SP du serveur sont bien
celles attendues pour la version X, et pas celles de la version X-N ?
> Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
> cahier des charges exhaustif
Le cahier des charges était exhaustif pour chaque version.
On parle bien d'évolutions plusieurs mois après la mise en prod uction.
Dans mon cas, il s'agissait d'un système de gestion de transactions
bancaires et l'évolution consistait à ajouter de nouveaux crit ères de
calcul (en gros des champs dans les tables, et là on a pleuré d e ne pas
avoir mis de « SELECT * »â¦)
> - ET avant tout se rappeler qu'un pro a le DEVOIR
> (juridique!) de dire non à son client si ses desiderati sont farfe lus.
à l'instant T0 de la signature du contrat, ils n'étaient pas fa rfelus.
à l'instant T0+18mois et 500 SP plus tard, ça l'est devenu un p eu plusâ¦
> J'ai souvenir d'un ami a qui le commercial a refilé un dossier; ap rès
> (courte) analyse ce que voulait principalement le client se résuma it Ã
> 30,000 hits à la seconde...
Cas classique, mais à la réponse à un appel d'offre et ava nt la
signature du contrat, il est souvent difficile de voir tous les futurs
points de blocage, d'autant plus que le client se gardera bien de te
signaler ceux qu'il a déjà anticipés,
et que toi tu es pressé par les délais (4 jours pour répon dre à un appel
d'offre de 1.000 pages).
> Explique-moi la diff que tu vois entre entre des morceaux de php et
> différentes PS?
Physiquement parlant, il n'y en a aucune, tout n'est que fichiers au fina l.
« Métièrement » parlant, un monde sépare les 2, d'autant plus si on sort
du monde PHP.
Je peux par exemple m'appuyer sur la POO (héritage, polymorphisme,
généricité, abstractionâ¦) pour limiter la duplicat ion, centraliser
l'information, factoriser mon codeâ¦
Un exemple à la con : il y a de fortes chances pour que le nom de mes
tables se trouvent à un seul endroit dans mon code, quand chaque SP
devra dupliquer l'information. Idem si j'ai 2 requêtes « identi ques mais
pas tout à fait », fortes chances d'arriver à factoriser t out ça au
niveau code quand les SP feront un gros copié/collé de derrià ¨re les fagots.
> Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a c e rôle).
J'ai toujours du mal à voir comment.
Le but du MVC est d'obtenir une page quasi-HTML (ie. débarrasée de toute
présence de code métier) d'un côté et toute la rà ©cupération des données
de l'autre, de séparer la forme et le contenu en somme.
SP ou pas, ça n'a pas de rapport, ça ne reste que la partie M d u MVC
(qui est ma DAO en JEE par exemple), il te manque encore toute la partie
C et V
> Par ailleurs je reste persuadé que l'archi 3-tiers est très l oin d'être une
> panacée universelle; contrairement à ce que pense notamment l a plupart des
> programmeurs, notamment web.
> Le 3-tiers est utile dans certains types d'applis bien particulièr es, pas
> dans toutes.
Ãa se prête généralement pas trop mal à tout typ e d'application.
Le gros avantage du N-tiers est de permettre des évolutions (mé tier,
physique ou technique) très faciles.
Je change de moteur de base sans rien faire. Je remplace ma DAO JPA par
une couche web-service ou tes SP en 10min. Je scallabilise ma couche
service en 30 min.
> C'est comme pour les sites qui mettent 3' à charger la page de gar de, ça
> n'est pas parce qu'on a un quadri-CPU en dev qu'on ne doit pas penser Ã
> ceux qui surfent avec un P3-500 - beaucoup, si ce n'est la plupart,
> devraient bien se rentrer cela dans la tête.
Certes, mais en même temps, quand tu tapes dans une table de 2To, pas
sûr que le temps de chargement du navigateur soit celui à prend re en
compte =)
Pour moi, une PS, c'est ni plus ni moins que du SQL enrobé dans une méthode.
Si on commence à y intégrer du code métier, j'ai l'impress ion qu'on
s'éloigne très fortement de l'objectif des PS.
Oui, ça d'accord, mais les PS sont quand même ultra-limité esâ¦
Elles ne supportent pas les arguments optionnels par exemple.
Comme je te l'ai mentionné, je ne vois pas comment on peut, via du P S,
arriver à faire ce genre de trucs (pseudo-code, et non sécurita ire je le
précise avant que ça n'hurle ^_^) :
function getTopics ( string[] sortOrders ) {
return "SELECT * FROM topics ORDER BY " + sortOrders.join(",");
}
Le fait d'avoir une requête SQL « dynamique » est pour moi en totale
contradiction avec le fonctionnement même des SP. Ou en tout cas, je ne
vois pas d'autres solutions que de faire :
function getTopics ( string[] sortOrders ) {
if sortOrders.is("date", "author")
return callSPGetTopicsOrderByDateAndAuthor()
else if sortOrders.is("date")
return callSPGetTopicsOrderByDate()
else if sortOrders.is("author")
return callSPGetTopicsOrderByAuthor()
else
return callSPGetTopics()
}
On voit bien l'explosion exponentielle du nombre de SPâ¦
La seule solution que je puisse entrevoir serait de faire :
function getTopics ( string[] sortOrders ) {
return callSPGetTopicsGeneric(sortOrders)
}
ce qui reviendrait à faire descendre les contrôles de sécu rité à la SP
au lieu du PHP, et en plus je n'ose trop imaginer la tronche finale de
la SP qui doit traiter TOUS les cas de requétage de l'application
(ordres de tri, colonnes remontées, jointures possibles (bonjour la
gestion de la sécurité avec les alias qui en découlent⠦), critères de
sélectionsâ¦).
Certes, le « SELECT * » n'est pas recommandé. Mais il a l' avantage de
permettre d'être justement indépendant des SDD derrière : si je modifie
ma table source, je n'ai pas à modifier ma requète !
Le fait de limiter la clause SELECT :
â bride l'application pour toute évolution future
â demande X requètes/SP si j'ai la même « requà ªte »-métier mais avec
dans chaque cas un besoin de colonnes de sortie différent
Il est plus facile de modifier un fichier de mapping de l'ORM / modifier
ma classe de DAO / grepper dans mes fichiers PHP (dans l'ordre de
préférence) que de grepper dans une foultitude de SP.
Surtout que supprimer un champ dans une SP, ça va encore, « gre p » le
verra. Mais difficile de grepper un champ qui n'existe pas encore parce
qu'on veut l'ajouter.
Et quid de la difficulté de s'assurer que les SP du serveur sont bien
celles attendues pour la version X, et pas celles de la version X-N ?
> Dans ce cas (comme dans les autres), il *FAUT* faire signer au client un
> cahier des charges exhaustif
Le cahier des charges était exhaustif pour chaque version.
On parle bien d'évolutions plusieurs mois après la mise en prod uction.
Dans mon cas, il s'agissait d'un système de gestion de transactions
bancaires et l'évolution consistait à ajouter de nouveaux crit ères de
calcul (en gros des champs dans les tables, et là on a pleuré d e ne pas
avoir mis de « SELECT * »â¦)
> - ET avant tout se rappeler qu'un pro a le DEVOIR
> (juridique!) de dire non à son client si ses desiderati sont farfe lus.
à l'instant T0 de la signature du contrat, ils n'étaient pas fa rfelus.
à l'instant T0+18mois et 500 SP plus tard, ça l'est devenu un p eu plusâ¦
> J'ai souvenir d'un ami a qui le commercial a refilé un dossier; ap rès
> (courte) analyse ce que voulait principalement le client se résuma it Ã
> 30,000 hits à la seconde...
Cas classique, mais à la réponse à un appel d'offre et ava nt la
signature du contrat, il est souvent difficile de voir tous les futurs
points de blocage, d'autant plus que le client se gardera bien de te
signaler ceux qu'il a déjà anticipés,
et que toi tu es pressé par les délais (4 jours pour répon dre à un appel
d'offre de 1.000 pages).
> Explique-moi la diff que tu vois entre entre des morceaux de php et
> différentes PS?
Physiquement parlant, il n'y en a aucune, tout n'est que fichiers au fina l.
« Métièrement » parlant, un monde sépare les 2, d'autant plus si on sort
du monde PHP.
Je peux par exemple m'appuyer sur la POO (héritage, polymorphisme,
généricité, abstractionâ¦) pour limiter la duplicat ion, centraliser
l'information, factoriser mon codeâ¦
Un exemple à la con : il y a de fortes chances pour que le nom de mes
tables se trouvent à un seul endroit dans mon code, quand chaque SP
devra dupliquer l'information. Idem si j'ai 2 requêtes « identi ques mais
pas tout à fait », fortes chances d'arriver à factoriser t out ça au
niveau code quand les SP feront un gros copié/collé de derrià ¨re les fagots.
> Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a c e rôle).
J'ai toujours du mal à voir comment.
Le but du MVC est d'obtenir une page quasi-HTML (ie. débarrasée de toute
présence de code métier) d'un côté et toute la rà ©cupération des données
de l'autre, de séparer la forme et le contenu en somme.
SP ou pas, ça n'a pas de rapport, ça ne reste que la partie M d u MVC
(qui est ma DAO en JEE par exemple), il te manque encore toute la partie
C et V
> Par ailleurs je reste persuadé que l'archi 3-tiers est très l oin d'être une
> panacée universelle; contrairement à ce que pense notamment l a plupart des
> programmeurs, notamment web.
> Le 3-tiers est utile dans certains types d'applis bien particulièr es, pas
> dans toutes.
Ãa se prête généralement pas trop mal à tout typ e d'application.
Le gros avantage du N-tiers est de permettre des évolutions (mé tier,
physique ou technique) très faciles.
Je change de moteur de base sans rien faire. Je remplace ma DAO JPA par
une couche web-service ou tes SP en 10min. Je scallabilise ma couche
service en 30 min.
> C'est comme pour les sites qui mettent 3' à charger la page de gar de, ça
> n'est pas parce qu'on a un quadri-CPU en dev qu'on ne doit pas penser Ã
> ceux qui surfent avec un P3-500 - beaucoup, si ce n'est la plupart,
> devraient bien se rentrer cela dans la tête.
Certes, mais en même temps, quand tu tapes dans une table de 2To, pas
sûr que le temps de chargement du navigateur soit celui à prend re en
compte =)
Tu dois autoriser le port 3306 que pour le localhost (si c'est possible).
Tu dois autoriser le port 3306 que pour le localhost (si c'est possible).
Tu dois autoriser le port 3306 que pour le localhost (si c'est possible).
Pour faire court: php a pillé perl; perl n'est pas un mauvais langage mais
tout comme C il permet le plus agréable des codes comme le plus illisible
et pourri possible.
Pour faire court: php a pillé perl; perl n'est pas un mauvais langage mais
tout comme C il permet le plus agréable des codes comme le plus illisible
et pourri possible.
Pour faire court: php a pillé perl; perl n'est pas un mauvais langage mais
tout comme C il permet le plus agréable des codes comme le plus illisible
et pourri possible.
Et c'est justement là que tu trompes: une PS ça *peut* être aussi simple qu'un
"SELECT col1,col2col3 FROM matable", mais c'est aussi et surtout capable de
beaucoup plus.
D'abord c'est écrit dans un langage structuré (SQL certes, mais aussi Pl/pgSQL,
Pl/Python, Pl/LUA, Pl/C, etc), c'est en prise +/- directe avec les données
(dépendant des droits d'exécution), mais c'est surtout intégré directement dans
la DB, donc ça dépend des mécanismes de contrôle de la DB qui
sont /sensiblement/ plus élaborés que ceux de php (au hasard).
Ca permet aussi de remplacer certaines VIEWs trop complexes à manier/modifier,
notamment en maintenance.
J'ai mis presque une année à intégrer le fonctionnement, l'analyse et
l'application de tout ça à un résultat final parce que justement, même si ça
reste de la logique, elle est différent de celle de la programmation.
Ca n'est pas pour rien que les devs de gros projets sont complètement séparés
entre programmation et DB: ce ne sont pas les même métiers (un peu comme
Erlang est totalement alien à celui qui ne fait que du Basic).
Mais si on fait (tjrs en symbolique):
CASE 1:
RETURN SORTED BY Date
CASE 2:
RETURN SORTED BY Author
CASE 4:
RETURN SORTED BY Date AND Author
DEFAULT:
RAISE ERROR maPSamoi, "Illegal sort switch"
END CASE
on n'a plus qu'une seule PS.
D'abord il faut savoir si TOUS ces cas de tris ont une réelle légitimité...
Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
justement maximale, en l'occurence dans la DB.
C'est justement pour cela que j'appelle ça une erreur de débutant:
1- Rien dans les différents normatifs SQL ne garantie l'ordre de retour des
données (col1,col2,col3 ou col2,col3,col1 ou...) et c'est ce qui déconseille
formellement le '*',
2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
3- À partir du moment où l'on a compris que la bonne syntaxe est de
nommer et ordonner les colonnes dans la requête, la maintenance d'un code
qu'il soit interne ou externe est strictement la même.
Dans l'état actuel des choses, un ORM est une ineptie - tout au plus peut il
servir lors d'une phase de mise au point.
Pourquoi en rajouter une couche (qui ralentit fortement l'ensemble) alors
qu'une bonne conception évite cela??
Là, je ne veux pas être méchant mais si tu distribues une MàJ du code php sans
celle de la DB, faut changer de métier tout de suite: c'est un tout.
Les prospectives AUSSI doivent être évoquées - et cela à tous les niveaux: que
cela soit avec les informaticiens locaux, les utilisateurs, les cadres et les
décideurs; c'est la seule façon d'obtenir une vue d'ensemble de la chose et
d'éviter les télescopages entre les désirs des uns et les impératifs des
autres.
Ca évite une bonne partie des mauvaises surprises futures.
Là il ne peut y avoir que 2 poss: soit l'analyse a été mal faite, soit le
client n'a pas été clair (voire un peu des 2).
Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
conception de la DB.
Les clauses réservatives sont là pour ça, d'ailleurs un contrat sur appel
d'offre ne devrait *jamais* être signé sans l'approbation d'un cabinet
d'avocat spécialisé.
Physiquement parlant, il n'y en a aucune, tout n'est que fichiers au final.
« Métièrement » parlant, un monde sépare les 2, d'autant plus si on sort
du monde PHP.
O_o tu fais de la POO en php...
Et si le nom de la table n'était qu'un parm d'appel de la PS?
Voila une idée qu'elle est bonne! (et qu'elle permet de réutiliser la PS avec
d'autres tables).
Quelle est la différence entre mettre en page du code qui vient d'une requête
en php et celui qui vient d'une PS; perso, j'vois pas (partie V).
Pour la partie C, elle est aussi incluse dans la PS.
Chaque outil a ses propres spécificités; par exemple tu peux faire tout ce que
tu veux en N-tiers en matière de communications, mais je te mettrais toujours
une pallée en utilisant Erlang et en scalant mon système en 3 lignes de code
sur un nombre illimité de nodes en qq secondes.
La bonne question c'est: est-ce qu'utiliser ceci ou cela apporte vraiment de
l'eau au moulin ou est-ce juste un pis aller pour aller plus vite (en Gal au
détriment de l'évolution).
Un tout ch'tit exemple: tu dis "Je change de moteur de base sans rien faire"
sauf que chaque DB a certaines spécifités et que certaines, même hors normes
SQL, facilitent grandement la vie.
Un autre: ça ne me viendrait même pas à l'esprit ne serait-ce qu'envisager
d'éventuellement un jour peut-être de penser à mysql pour une appli sérieuse.
Quand bien même la table ferait 2T *rows*, c'est juste une question de
conception correcte de la DB, de ses indexes, de ses PS et de ses requêtes
(considérant que le hard a été au préalable correctement dimensionné).
Et c'est justement là que tu trompes: une PS ça *peut* être aussi simple qu'un
"SELECT col1,col2col3 FROM matable", mais c'est aussi et surtout capable de
beaucoup plus.
D'abord c'est écrit dans un langage structuré (SQL certes, mais aussi Pl/pgSQL,
Pl/Python, Pl/LUA, Pl/C, etc), c'est en prise +/- directe avec les données
(dépendant des droits d'exécution), mais c'est surtout intégré directement dans
la DB, donc ça dépend des mécanismes de contrôle de la DB qui
sont /sensiblement/ plus élaborés que ceux de php (au hasard).
Ca permet aussi de remplacer certaines VIEWs trop complexes à manier/modifier,
notamment en maintenance.
J'ai mis presque une année à intégrer le fonctionnement, l'analyse et
l'application de tout ça à un résultat final parce que justement, même si ça
reste de la logique, elle est différent de celle de la programmation.
Ca n'est pas pour rien que les devs de gros projets sont complètement séparés
entre programmation et DB: ce ne sont pas les même métiers (un peu comme
Erlang est totalement alien à celui qui ne fait que du Basic).
Mais si on fait (tjrs en symbolique):
CASE 1:
RETURN SORTED BY Date
CASE 2:
RETURN SORTED BY Author
CASE 4:
RETURN SORTED BY Date AND Author
DEFAULT:
RAISE ERROR maPSamoi, "Illegal sort switch"
END CASE
on n'a plus qu'une seule PS.
D'abord il faut savoir si TOUS ces cas de tris ont une réelle légitimité...
Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
justement maximale, en l'occurence dans la DB.
C'est justement pour cela que j'appelle ça une erreur de débutant:
1- Rien dans les différents normatifs SQL ne garantie l'ordre de retour des
données (col1,col2,col3 ou col2,col3,col1 ou...) et c'est ce qui déconseille
formellement le '*',
2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
3- À partir du moment où l'on a compris que la bonne syntaxe est de
nommer et ordonner les colonnes dans la requête, la maintenance d'un code
qu'il soit interne ou externe est strictement la même.
Dans l'état actuel des choses, un ORM est une ineptie - tout au plus peut il
servir lors d'une phase de mise au point.
Pourquoi en rajouter une couche (qui ralentit fortement l'ensemble) alors
qu'une bonne conception évite cela??
Là, je ne veux pas être méchant mais si tu distribues une MàJ du code php sans
celle de la DB, faut changer de métier tout de suite: c'est un tout.
Les prospectives AUSSI doivent être évoquées - et cela à tous les niveaux: que
cela soit avec les informaticiens locaux, les utilisateurs, les cadres et les
décideurs; c'est la seule façon d'obtenir une vue d'ensemble de la chose et
d'éviter les télescopages entre les désirs des uns et les impératifs des
autres.
Ca évite une bonne partie des mauvaises surprises futures.
Là il ne peut y avoir que 2 poss: soit l'analyse a été mal faite, soit le
client n'a pas été clair (voire un peu des 2).
Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
conception de la DB.
Les clauses réservatives sont là pour ça, d'ailleurs un contrat sur appel
d'offre ne devrait *jamais* être signé sans l'approbation d'un cabinet
d'avocat spécialisé.
Physiquement parlant, il n'y en a aucune, tout n'est que fichiers au final.
« Métièrement » parlant, un monde sépare les 2, d'autant plus si on sort
du monde PHP.
O_o tu fais de la POO en php...
Et si le nom de la table n'était qu'un parm d'appel de la PS?
Voila une idée qu'elle est bonne! (et qu'elle permet de réutiliser la PS avec
d'autres tables).
Quelle est la différence entre mettre en page du code qui vient d'une requête
en php et celui qui vient d'une PS; perso, j'vois pas (partie V).
Pour la partie C, elle est aussi incluse dans la PS.
Chaque outil a ses propres spécificités; par exemple tu peux faire tout ce que
tu veux en N-tiers en matière de communications, mais je te mettrais toujours
une pallée en utilisant Erlang et en scalant mon système en 3 lignes de code
sur un nombre illimité de nodes en qq secondes.
La bonne question c'est: est-ce qu'utiliser ceci ou cela apporte vraiment de
l'eau au moulin ou est-ce juste un pis aller pour aller plus vite (en Gal au
détriment de l'évolution).
Un tout ch'tit exemple: tu dis "Je change de moteur de base sans rien faire"
sauf que chaque DB a certaines spécifités et que certaines, même hors normes
SQL, facilitent grandement la vie.
Un autre: ça ne me viendrait même pas à l'esprit ne serait-ce qu'envisager
d'éventuellement un jour peut-être de penser à mysql pour une appli sérieuse.
Quand bien même la table ferait 2T *rows*, c'est juste une question de
conception correcte de la DB, de ses indexes, de ses PS et de ses requêtes
(considérant que le hard a été au préalable correctement dimensionné).
Et c'est justement là que tu trompes: une PS ça *peut* être aussi simple qu'un
"SELECT col1,col2col3 FROM matable", mais c'est aussi et surtout capable de
beaucoup plus.
D'abord c'est écrit dans un langage structuré (SQL certes, mais aussi Pl/pgSQL,
Pl/Python, Pl/LUA, Pl/C, etc), c'est en prise +/- directe avec les données
(dépendant des droits d'exécution), mais c'est surtout intégré directement dans
la DB, donc ça dépend des mécanismes de contrôle de la DB qui
sont /sensiblement/ plus élaborés que ceux de php (au hasard).
Ca permet aussi de remplacer certaines VIEWs trop complexes à manier/modifier,
notamment en maintenance.
J'ai mis presque une année à intégrer le fonctionnement, l'analyse et
l'application de tout ça à un résultat final parce que justement, même si ça
reste de la logique, elle est différent de celle de la programmation.
Ca n'est pas pour rien que les devs de gros projets sont complètement séparés
entre programmation et DB: ce ne sont pas les même métiers (un peu comme
Erlang est totalement alien à celui qui ne fait que du Basic).
Mais si on fait (tjrs en symbolique):
CASE 1:
RETURN SORTED BY Date
CASE 2:
RETURN SORTED BY Author
CASE 4:
RETURN SORTED BY Date AND Author
DEFAULT:
RAISE ERROR maPSamoi, "Illegal sort switch"
END CASE
on n'a plus qu'une seule PS.
D'abord il faut savoir si TOUS ces cas de tris ont une réelle légitimité...
Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
justement maximale, en l'occurence dans la DB.
C'est justement pour cela que j'appelle ça une erreur de débutant:
1- Rien dans les différents normatifs SQL ne garantie l'ordre de retour des
données (col1,col2,col3 ou col2,col3,col1 ou...) et c'est ce qui déconseille
formellement le '*',
2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
3- À partir du moment où l'on a compris que la bonne syntaxe est de
nommer et ordonner les colonnes dans la requête, la maintenance d'un code
qu'il soit interne ou externe est strictement la même.
Dans l'état actuel des choses, un ORM est une ineptie - tout au plus peut il
servir lors d'une phase de mise au point.
Pourquoi en rajouter une couche (qui ralentit fortement l'ensemble) alors
qu'une bonne conception évite cela??
Là, je ne veux pas être méchant mais si tu distribues une MàJ du code php sans
celle de la DB, faut changer de métier tout de suite: c'est un tout.
Les prospectives AUSSI doivent être évoquées - et cela à tous les niveaux: que
cela soit avec les informaticiens locaux, les utilisateurs, les cadres et les
décideurs; c'est la seule façon d'obtenir une vue d'ensemble de la chose et
d'éviter les télescopages entre les désirs des uns et les impératifs des
autres.
Ca évite une bonne partie des mauvaises surprises futures.
Là il ne peut y avoir que 2 poss: soit l'analyse a été mal faite, soit le
client n'a pas été clair (voire un peu des 2).
Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
conception de la DB.
Les clauses réservatives sont là pour ça, d'ailleurs un contrat sur appel
d'offre ne devrait *jamais* être signé sans l'approbation d'un cabinet
d'avocat spécialisé.
Physiquement parlant, il n'y en a aucune, tout n'est que fichiers au final.
« Métièrement » parlant, un monde sépare les 2, d'autant plus si on sort
du monde PHP.
O_o tu fais de la POO en php...
Et si le nom de la table n'était qu'un parm d'appel de la PS?
Voila une idée qu'elle est bonne! (et qu'elle permet de réutiliser la PS avec
d'autres tables).
Quelle est la différence entre mettre en page du code qui vient d'une requête
en php et celui qui vient d'une PS; perso, j'vois pas (partie V).
Pour la partie C, elle est aussi incluse dans la PS.
Chaque outil a ses propres spécificités; par exemple tu peux faire tout ce que
tu veux en N-tiers en matière de communications, mais je te mettrais toujours
une pallée en utilisant Erlang et en scalant mon système en 3 lignes de code
sur un nombre illimité de nodes en qq secondes.
La bonne question c'est: est-ce qu'utiliser ceci ou cela apporte vraiment de
l'eau au moulin ou est-ce juste un pis aller pour aller plus vite (en Gal au
détriment de l'évolution).
Un tout ch'tit exemple: tu dis "Je change de moteur de base sans rien faire"
sauf que chaque DB a certaines spécifités et que certaines, même hors normes
SQL, facilitent grandement la vie.
Un autre: ça ne me viendrait même pas à l'esprit ne serait-ce qu'envisager
d'éventuellement un jour peut-être de penser à mysql pour une appli sérieuse.
Quand bien même la table ferait 2T *rows*, c'est juste une question de
conception correcte de la DB, de ses indexes, de ses PS et de ses requêtes
(considérant que le hard a été au préalable correctement dimensionné).
OK, mais on sort totalement du cadre des procédures stockées la mbdaâ¦
Et entre mettre du code dans la db ou du code dans l'appli, pour moi
c'est du pareil au même, et sauf à demander 2à plus de tra vail et de
personnes, je n'en vois pas l'intérêt.
Bien que je ne maîtrise pas ce que permet de telles SP au niveau
sécurité DB, j'imagine assez mal ne pas pouvoir faire ce type de
contrôle au niveau applicatif. Peut-être me trompé-je⠦
Et qui dit 2 sources de code dit 2Ã plus de risque d'erreur !
> J'ai mis presque une année à intégrer le fonctionnement, l'analyse et
> l'application de tout ça à un résultat final parce que j ustement, même si
> ça reste de la logique, elle est différent de celle de la pro grammation.
Gros problème que j'y vois : cette manière de penser (que j'ima gine bien
loin de tout standard SQL et reposant sur des API propres au moteur
utilisé), est totalement non portable, réutilisable ou gén éralisable.
Tu changes de moteur, ton année de travail aura été totale ment vain.
> Ca n'est pas pour rien que les devs de gros projets sont complètem ent
> séparés entre programmation et DB: ce ne sont pas les mê me métiers (un peu
> comme Erlang est totalement alien à celui qui ne fait que du Basic ).
Euh, sur de gros projets, les DBA s'occupent de la structuration des
données (schémas, indexes, configuration et paramétrage du moteurâ¦), pas
du développementâ¦
> Mais si on fait (tjrs en symbolique):
> CASE 1:
> RETURN SORTED BY Date
> CASE 2:
> RETURN SORTED BY Author
> CASE 4:
> RETURN SORTED BY Date AND Author
> DEFAULT:
> RAISE ERROR maPSamoi, "Illegal sort switch"
> END CASE
>
> on n'a plus qu'une seule PS.
C'est effectivement la solution que j'envisageait.
Mais dans une application classique, je pense que N tend plus vers 200
que vers 5â¦
> D'abord il faut savoir si TOUS ces cas de tris ont une réelle là ©gitimité...
Dans une application « classique », oui.
Par exemple dans les écrans de reporting et/ou de traçabilità ©.
> Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
> justement maximale, en l'occurence dans la DB.
Pas convaincuâ¦
J'ai l'exemple d'une de mes applis de gestion biométriques où l es
données nominatives n'étaient accessibles que par les admins du système.
Une partie du contrôle des accès aux colonnes de la db éta it donc Ã
faire au niveau applicatif !
> C'est justement pour cela que j'appelle ça une erreur de débu tant:
> 1- Rien dans les différents normatifs SQL ne garantie l'ordre de r etour des
> données (col1,col2,col3 ou col2,col3,col1 ou...) et c'est ce qui
> déconseille formellement le '*',
C'est pour ça que je n'utilise pas le positionnel, mais bien les cha mps
nommés.
> 2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
Ce qui ouvre la voie à de l'injection SQL ? =)
> Dans l'état actuel des choses, un ORM est une ineptie - tout au pl us peut
> il servir lors d'une phase de mise au point.
> Pourquoi en rajouter une couche (qui ralentit fortement l'ensemble) alo rs
> qu'une bonne conception évite cela??
Un ORM, c'est pas juste un bidule qui te connecte à la baseâ¦
Ãa t'apporte pas mal d'autres choses, comme les pools de connexion, les
caches multi-niveaux, l'indépendance du moteurâ¦
> Là , je ne veux pas être méchant mais si tu distribues un e Mà J du code php
> sans celle de la DB, faut changer de métier tout de suite: c'est u n tout.
Si le monde était aussi rose, ça se saurait depuis longtemps =)
Et je peux très facilement vérifier que mon client a exactement les
mêmes fichiers que moi en production (MD5), il en est autrement pour les
SP potentielles sur le moteurâ¦
Un client a souvent du mal à définir son futur, surtout à 18 ou 30 mois.
J'ai même dans mon entreprise des demandes d'évolution sur du s oft de 30
ans d'âge !
> Là il ne peut y avoir que 2 poss: soit l'analyse a été m al faite, soit le
> client n'a pas été clair (voire un peu des 2).
Non, juste que tout faire en SP ne nous semblait pas impossible
techniquement, et reste d'ailleurs même encore aujourd'hui complà ¨tement
faisable.
Le soucis est venu au cours du développement, quand on a commencà © à voir
le nombre de SP, avec X variantes de la même requête, mais avec plus ou
moins de données sortantes, de critères de sélection ou de triâ¦
Les développeurs s'arrachaient la tête pour savoir si une fonct ionnalité
avait déjà été SPifié ou si le travail restait à faire, pour trouver
telle SP qui devait être corrigée, ainsi que toutes ses variati ons
potentielles.
> Mais dans le cas présent, je soupçonne fortement (et à p riori) un défaut de
> conception de la DB.
C'était le cas en partie, mais la base avait été héri tée d'un ancien
système et on ne pouvait pas trop y toucher.
Et pour achever le coup des SP, la plupart des requêtes étaient
dépendantes d'un fichier de conf (XML) qui définissaient les r ègles
métiers (répartition fonction du client, taxes variables, frais,
ristournes commercialesâ¦).
Le nombre de paramètres à passer aux SPs étaient effroyabl es (jusqu'Ã
300 paramètres pour la plus grosse de mémoire).
> Les clauses réservatives sont là pour ça, d'ailleurs un contrat sur appel
> d'offre ne devrait *jamais* être signé sans l'approbation d'u n cabinet
> d'avocat spécialisé.
Les clauses sont là , mais rarement appliquées.
> Et si le nom de la table n'était qu'un parm d'appel de la PS?
> Voila une idée qu'elle est bonne! (et qu'elle permet de réuti liser la PS
> avec d'autres tables).
Et de redescendre l'injection SQL un poil plus basâ¦
> Pour la partie C, elle est aussi incluse dans la PS.
Gné ?
Ãa devient limite de l'hérésie là â¦
Le jour où je rajoute des écrans, je dois toucher à ma BdD ? Oo
> Chaque outil a ses propres spécificités; par exemple tu peux faire tout ce
> que tu veux en N-tiers en matière de communications, mais je te me ttrais
> toujours une pallée en utilisant Erlang et en scalant mon systà ¨me en 3
> lignes de code sur un nombre illimité de nodes en qq secondes.
Certes, mais qui pourra maintenir ton code derrière ?
Non pas que je défende qu'on doit pouvoir refiler la reprise de code au
premier venu, mais à l'inverse, s'il faut que la recrue mette la m ême
année que toi à comprendre le langage / systèmeâ¦
> La bonne question c'est: est-ce qu'utiliser ceci ou cela apporte vraime nt
> de l'eau au moulin ou est-ce juste un pis aller pour aller plus vite (en
> Gal au détriment de l'évolution).
Oui, Ã long terme.
On sait d'avance que les évolutions seront nombreuses (surtout dans mon
domaine principal, l'industrie), et les équipes très fluctuante s (SSII).
Le soft se doit d'être abordable tout en étant suffisamment bie n gaulé.
> Un tout ch'tit exemple: tu dis "Je change de moteur de base sans rien
> faire" sauf que chaque DB a certaines spécifités et que certa ines, même
> hors normes SQL, facilitent grandement la vie.
C'est pour ça que Hibernate définit la notion de dialecte et se base sur
les API propres à chaque moteur (non pas comme certains le pense en se
conformant à la stricte norme SQL).
Il utilisera par exemple les serial et séquences de PostgreSQL au li eu
de l'auto-incrément MySQL.
> Un autre: ça ne me viendrait même pas à l'esprit ne sera it-ce qu'envisager
> d'éventuellement un jour peut-être de penser à mysql pou r une appli
> sérieuse.
C'est bien pour ça que je l'ai fait bannir de notre bureau d'ét udes.
Comme remplaçant, PostgreSQL !
OK, mais on sort totalement du cadre des procédures stockées la mbdaâ¦
Et entre mettre du code dans la db ou du code dans l'appli, pour moi
c'est du pareil au même, et sauf à demander 2à plus de tra vail et de
personnes, je n'en vois pas l'intérêt.
Bien que je ne maîtrise pas ce que permet de telles SP au niveau
sécurité DB, j'imagine assez mal ne pas pouvoir faire ce type de
contrôle au niveau applicatif. Peut-être me trompé-je⠦
Et qui dit 2 sources de code dit 2Ã plus de risque d'erreur !
> J'ai mis presque une année à intégrer le fonctionnement, l'analyse et
> l'application de tout ça à un résultat final parce que j ustement, même si
> ça reste de la logique, elle est différent de celle de la pro grammation.
Gros problème que j'y vois : cette manière de penser (que j'ima gine bien
loin de tout standard SQL et reposant sur des API propres au moteur
utilisé), est totalement non portable, réutilisable ou gén éralisable.
Tu changes de moteur, ton année de travail aura été totale ment vain.
> Ca n'est pas pour rien que les devs de gros projets sont complètem ent
> séparés entre programmation et DB: ce ne sont pas les mê me métiers (un peu
> comme Erlang est totalement alien à celui qui ne fait que du Basic ).
Euh, sur de gros projets, les DBA s'occupent de la structuration des
données (schémas, indexes, configuration et paramétrage du moteurâ¦), pas
du développementâ¦
> Mais si on fait (tjrs en symbolique):
> CASE 1:
> RETURN SORTED BY Date
> CASE 2:
> RETURN SORTED BY Author
> CASE 4:
> RETURN SORTED BY Date AND Author
> DEFAULT:
> RAISE ERROR maPSamoi, "Illegal sort switch"
> END CASE
>
> on n'a plus qu'une seule PS.
C'est effectivement la solution que j'envisageait.
Mais dans une application classique, je pense que N tend plus vers 200
que vers 5â¦
> D'abord il faut savoir si TOUS ces cas de tris ont une réelle là ©gitimité...
Dans une application « classique », oui.
Par exemple dans les écrans de reporting et/ou de traçabilità ©.
> Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
> justement maximale, en l'occurence dans la DB.
Pas convaincuâ¦
J'ai l'exemple d'une de mes applis de gestion biométriques où l es
données nominatives n'étaient accessibles que par les admins du système.
Une partie du contrôle des accès aux colonnes de la db éta it donc Ã
faire au niveau applicatif !
> C'est justement pour cela que j'appelle ça une erreur de débu tant:
> 1- Rien dans les différents normatifs SQL ne garantie l'ordre de r etour des
> données (col1,col2,col3 ou col2,col3,col1 ou...) et c'est ce qui
> déconseille formellement le '*',
C'est pour ça que je n'utilise pas le positionnel, mais bien les cha mps
nommés.
> 2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
Ce qui ouvre la voie à de l'injection SQL ? =)
> Dans l'état actuel des choses, un ORM est une ineptie - tout au pl us peut
> il servir lors d'une phase de mise au point.
> Pourquoi en rajouter une couche (qui ralentit fortement l'ensemble) alo rs
> qu'une bonne conception évite cela??
Un ORM, c'est pas juste un bidule qui te connecte à la baseâ¦
Ãa t'apporte pas mal d'autres choses, comme les pools de connexion, les
caches multi-niveaux, l'indépendance du moteurâ¦
> Là , je ne veux pas être méchant mais si tu distribues un e Mà J du code php
> sans celle de la DB, faut changer de métier tout de suite: c'est u n tout.
Si le monde était aussi rose, ça se saurait depuis longtemps =)
Et je peux très facilement vérifier que mon client a exactement les
mêmes fichiers que moi en production (MD5), il en est autrement pour les
SP potentielles sur le moteurâ¦
Un client a souvent du mal à définir son futur, surtout à 18 ou 30 mois.
J'ai même dans mon entreprise des demandes d'évolution sur du s oft de 30
ans d'âge !
> Là il ne peut y avoir que 2 poss: soit l'analyse a été m al faite, soit le
> client n'a pas été clair (voire un peu des 2).
Non, juste que tout faire en SP ne nous semblait pas impossible
techniquement, et reste d'ailleurs même encore aujourd'hui complà ¨tement
faisable.
Le soucis est venu au cours du développement, quand on a commencà © à voir
le nombre de SP, avec X variantes de la même requête, mais avec plus ou
moins de données sortantes, de critères de sélection ou de triâ¦
Les développeurs s'arrachaient la tête pour savoir si une fonct ionnalité
avait déjà été SPifié ou si le travail restait à faire, pour trouver
telle SP qui devait être corrigée, ainsi que toutes ses variati ons
potentielles.
> Mais dans le cas présent, je soupçonne fortement (et à p riori) un défaut de
> conception de la DB.
C'était le cas en partie, mais la base avait été héri tée d'un ancien
système et on ne pouvait pas trop y toucher.
Et pour achever le coup des SP, la plupart des requêtes étaient
dépendantes d'un fichier de conf (XML) qui définissaient les r ègles
métiers (répartition fonction du client, taxes variables, frais,
ristournes commercialesâ¦).
Le nombre de paramètres à passer aux SPs étaient effroyabl es (jusqu'Ã
300 paramètres pour la plus grosse de mémoire).
> Les clauses réservatives sont là pour ça, d'ailleurs un contrat sur appel
> d'offre ne devrait *jamais* être signé sans l'approbation d'u n cabinet
> d'avocat spécialisé.
Les clauses sont là , mais rarement appliquées.
> Et si le nom de la table n'était qu'un parm d'appel de la PS?
> Voila une idée qu'elle est bonne! (et qu'elle permet de réuti liser la PS
> avec d'autres tables).
Et de redescendre l'injection SQL un poil plus basâ¦
> Pour la partie C, elle est aussi incluse dans la PS.
Gné ?
Ãa devient limite de l'hérésie là â¦
Le jour où je rajoute des écrans, je dois toucher à ma BdD ? Oo
> Chaque outil a ses propres spécificités; par exemple tu peux faire tout ce
> que tu veux en N-tiers en matière de communications, mais je te me ttrais
> toujours une pallée en utilisant Erlang et en scalant mon systà ¨me en 3
> lignes de code sur un nombre illimité de nodes en qq secondes.
Certes, mais qui pourra maintenir ton code derrière ?
Non pas que je défende qu'on doit pouvoir refiler la reprise de code au
premier venu, mais à l'inverse, s'il faut que la recrue mette la m ême
année que toi à comprendre le langage / systèmeâ¦
> La bonne question c'est: est-ce qu'utiliser ceci ou cela apporte vraime nt
> de l'eau au moulin ou est-ce juste un pis aller pour aller plus vite (en
> Gal au détriment de l'évolution).
Oui, Ã long terme.
On sait d'avance que les évolutions seront nombreuses (surtout dans mon
domaine principal, l'industrie), et les équipes très fluctuante s (SSII).
Le soft se doit d'être abordable tout en étant suffisamment bie n gaulé.
> Un tout ch'tit exemple: tu dis "Je change de moteur de base sans rien
> faire" sauf que chaque DB a certaines spécifités et que certa ines, même
> hors normes SQL, facilitent grandement la vie.
C'est pour ça que Hibernate définit la notion de dialecte et se base sur
les API propres à chaque moteur (non pas comme certains le pense en se
conformant à la stricte norme SQL).
Il utilisera par exemple les serial et séquences de PostgreSQL au li eu
de l'auto-incrément MySQL.
> Un autre: ça ne me viendrait même pas à l'esprit ne sera it-ce qu'envisager
> d'éventuellement un jour peut-être de penser à mysql pou r une appli
> sérieuse.
C'est bien pour ça que je l'ai fait bannir de notre bureau d'ét udes.
Comme remplaçant, PostgreSQL !
OK, mais on sort totalement du cadre des procédures stockées la mbdaâ¦
Et entre mettre du code dans la db ou du code dans l'appli, pour moi
c'est du pareil au même, et sauf à demander 2à plus de tra vail et de
personnes, je n'en vois pas l'intérêt.
Bien que je ne maîtrise pas ce que permet de telles SP au niveau
sécurité DB, j'imagine assez mal ne pas pouvoir faire ce type de
contrôle au niveau applicatif. Peut-être me trompé-je⠦
Et qui dit 2 sources de code dit 2Ã plus de risque d'erreur !
> J'ai mis presque une année à intégrer le fonctionnement, l'analyse et
> l'application de tout ça à un résultat final parce que j ustement, même si
> ça reste de la logique, elle est différent de celle de la pro grammation.
Gros problème que j'y vois : cette manière de penser (que j'ima gine bien
loin de tout standard SQL et reposant sur des API propres au moteur
utilisé), est totalement non portable, réutilisable ou gén éralisable.
Tu changes de moteur, ton année de travail aura été totale ment vain.
> Ca n'est pas pour rien que les devs de gros projets sont complètem ent
> séparés entre programmation et DB: ce ne sont pas les mê me métiers (un peu
> comme Erlang est totalement alien à celui qui ne fait que du Basic ).
Euh, sur de gros projets, les DBA s'occupent de la structuration des
données (schémas, indexes, configuration et paramétrage du moteurâ¦), pas
du développementâ¦
> Mais si on fait (tjrs en symbolique):
> CASE 1:
> RETURN SORTED BY Date
> CASE 2:
> RETURN SORTED BY Author
> CASE 4:
> RETURN SORTED BY Date AND Author
> DEFAULT:
> RAISE ERROR maPSamoi, "Illegal sort switch"
> END CASE
>
> on n'a plus qu'une seule PS.
C'est effectivement la solution que j'envisageait.
Mais dans une application classique, je pense que N tend plus vers 200
que vers 5â¦
> D'abord il faut savoir si TOUS ces cas de tris ont une réelle là ©gitimité...
Dans une application « classique », oui.
Par exemple dans les écrans de reporting et/ou de traçabilità ©.
> Ensuite les contrôles de sécurité DOIVENT setrouver là où la sécurité est
> justement maximale, en l'occurence dans la DB.
Pas convaincuâ¦
J'ai l'exemple d'une de mes applis de gestion biométriques où l es
données nominatives n'étaient accessibles que par les admins du système.
Une partie du contrôle des accès aux colonnes de la db éta it donc Ã
faire au niveau applicatif !
> C'est justement pour cela que j'appelle ça une erreur de débu tant:
> 1- Rien dans les différents normatifs SQL ne garantie l'ordre de r etour des
> données (col1,col2,col3 ou col2,col3,col1 ou...) et c'est ce qui
> déconseille formellement le '*',
C'est pour ça que je n'utilise pas le positionnel, mais bien les cha mps
nommés.
> 2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
Ce qui ouvre la voie à de l'injection SQL ? =)
> Dans l'état actuel des choses, un ORM est une ineptie - tout au pl us peut
> il servir lors d'une phase de mise au point.
> Pourquoi en rajouter une couche (qui ralentit fortement l'ensemble) alo rs
> qu'une bonne conception évite cela??
Un ORM, c'est pas juste un bidule qui te connecte à la baseâ¦
Ãa t'apporte pas mal d'autres choses, comme les pools de connexion, les
caches multi-niveaux, l'indépendance du moteurâ¦
> Là , je ne veux pas être méchant mais si tu distribues un e Mà J du code php
> sans celle de la DB, faut changer de métier tout de suite: c'est u n tout.
Si le monde était aussi rose, ça se saurait depuis longtemps =)
Et je peux très facilement vérifier que mon client a exactement les
mêmes fichiers que moi en production (MD5), il en est autrement pour les
SP potentielles sur le moteurâ¦
Un client a souvent du mal à définir son futur, surtout à 18 ou 30 mois.
J'ai même dans mon entreprise des demandes d'évolution sur du s oft de 30
ans d'âge !
> Là il ne peut y avoir que 2 poss: soit l'analyse a été m al faite, soit le
> client n'a pas été clair (voire un peu des 2).
Non, juste que tout faire en SP ne nous semblait pas impossible
techniquement, et reste d'ailleurs même encore aujourd'hui complà ¨tement
faisable.
Le soucis est venu au cours du développement, quand on a commencà © à voir
le nombre de SP, avec X variantes de la même requête, mais avec plus ou
moins de données sortantes, de critères de sélection ou de triâ¦
Les développeurs s'arrachaient la tête pour savoir si une fonct ionnalité
avait déjà été SPifié ou si le travail restait à faire, pour trouver
telle SP qui devait être corrigée, ainsi que toutes ses variati ons
potentielles.
> Mais dans le cas présent, je soupçonne fortement (et à p riori) un défaut de
> conception de la DB.
C'était le cas en partie, mais la base avait été héri tée d'un ancien
système et on ne pouvait pas trop y toucher.
Et pour achever le coup des SP, la plupart des requêtes étaient
dépendantes d'un fichier de conf (XML) qui définissaient les r ègles
métiers (répartition fonction du client, taxes variables, frais,
ristournes commercialesâ¦).
Le nombre de paramètres à passer aux SPs étaient effroyabl es (jusqu'Ã
300 paramètres pour la plus grosse de mémoire).
> Les clauses réservatives sont là pour ça, d'ailleurs un contrat sur appel
> d'offre ne devrait *jamais* être signé sans l'approbation d'u n cabinet
> d'avocat spécialisé.
Les clauses sont là , mais rarement appliquées.
> Et si le nom de la table n'était qu'un parm d'appel de la PS?
> Voila une idée qu'elle est bonne! (et qu'elle permet de réuti liser la PS
> avec d'autres tables).
Et de redescendre l'injection SQL un poil plus basâ¦
> Pour la partie C, elle est aussi incluse dans la PS.
Gné ?
Ãa devient limite de l'hérésie là â¦
Le jour où je rajoute des écrans, je dois toucher à ma BdD ? Oo
> Chaque outil a ses propres spécificités; par exemple tu peux faire tout ce
> que tu veux en N-tiers en matière de communications, mais je te me ttrais
> toujours une pallée en utilisant Erlang et en scalant mon systà ¨me en 3
> lignes de code sur un nombre illimité de nodes en qq secondes.
Certes, mais qui pourra maintenir ton code derrière ?
Non pas que je défende qu'on doit pouvoir refiler la reprise de code au
premier venu, mais à l'inverse, s'il faut que la recrue mette la m ême
année que toi à comprendre le langage / systèmeâ¦
> La bonne question c'est: est-ce qu'utiliser ceci ou cela apporte vraime nt
> de l'eau au moulin ou est-ce juste un pis aller pour aller plus vite (en
> Gal au détriment de l'évolution).
Oui, Ã long terme.
On sait d'avance que les évolutions seront nombreuses (surtout dans mon
domaine principal, l'industrie), et les équipes très fluctuante s (SSII).
Le soft se doit d'être abordable tout en étant suffisamment bie n gaulé.
> Un tout ch'tit exemple: tu dis "Je change de moteur de base sans rien
> faire" sauf que chaque DB a certaines spécifités et que certa ines, même
> hors normes SQL, facilitent grandement la vie.
C'est pour ça que Hibernate définit la notion de dialecte et se base sur
les API propres à chaque moteur (non pas comme certains le pense en se
conformant à la stricte norme SQL).
Il utilisera par exemple les serial et séquences de PostgreSQL au li eu
de l'auto-incrément MySQL.
> Un autre: ça ne me viendrait même pas à l'esprit ne sera it-ce qu'envisager
> d'éventuellement un jour peut-être de penser à mysql pou r une appli
> sérieuse.
C'est bien pour ça que je l'ai fait bannir de notre bureau d'ét udes.
Comme remplaçant, PostgreSQL !
Bien que je ne maîtrise pas ce que permet de telles SP au niveau
sécurité DB, j'imagine assez mal ne pas pouvoir faire ce type de
contrôle au niveau applicatif. Peut-être me trompé-je…
Avec l'apparition de Pg ≥ 9.0 le contrôle est devenu bcp plus fin
(colonnes), il me parait donc logique que la DB s'occupe du contrôle
d'accès.
C'est en partie vrai, mais depuis qq temps on observe une
convergence, à mon avis non-fortuite, entre Pg & Oracle; et il n'y a
pas tant que cela d'autres compétiteurs du même niveau. C'est pour
cela que j'essaye de penser hors des sentiers battus; la portabilité
c'est Tbien dans l'abstrait, mais encore faut-il: * qu'il y ait un
intérêt quelconque à éventuellement switcher,
* qu'il existe un moteur capable de rendre les même services.
* que ladite portabilité ne se fasse pas au détriment des perfs.
Même si N00 ça ne pose pas de PB insoluble (surtout que dans Pg,
une
passé le premier appel qui déclenche la compilation, c'est le
pseudo-code qui est exécuté).
Pas convaincu… J'ai l'exemple d'une de mes applis de gestion
biométriques où les données nominatives n'étaient accessibles que
par les admins du système. Une partie du contrôle des accès aux
colonnes de la db était donc à faire au niveau applicatif !
Développe un peu plus parce que là je ne vois pas le tableau.
Ca n'est point ce que j'avions lû qq posts plus haut, gent
damoiseau!: "Certes, le « SELECT * » n'est pas recommandé. Mais il a
l'avantage de permettre d'être justement indépendant des SDD derrière
: si je modifie ma table source, je n'ai pas à modifier ma requète !"
SIC
Si j'ai besoin de pools et/ou de cache(s), je vais les chercher
individuellement là où ils sont 100% fonctionnels et très
performants, pas dans une soupe où l'on trouve tout et n'importe
quoi - souvent bricolés à la va-vite sur demande pressante des
utilisateurs.
Apparemment mauvaise analyse dûe à une connaissance pas assez
approfondie de la DB utilisée.
Dans ce cas, fais les passer en AGILE ou XP - je ne sais plus lequel
procède par releases rapides, mais c'est un système qui a bcp
d'avantages: release when ready AND tested, puis ajouts de
fonctionnalités par releases, jusqu'à release 1.0
Ha haaaa, la vieille base qu'on ne peut pas toucher - un must du
C'est aussi là que la préparation pêche: soit le client conserve sa
il encaisse *également* les inconvénients qui vont avec, soit il y a
migration et donc création d'une Nlle base.
Là encore, c'est une question d'analyse préalable - prendre un
marché, c'est bien, mais pas s'il doit se transformer en sables
mouvants dès le dev.
Là encore c'est un défaut d'analyse: comment accepter des données
externes alors qu'elles auraient dû se trouver dans la DB?
Pour te donner une idée, même les tailles & positionnements des
mon projet sont stockés dans la DB.
Une fois que c'est fait, on définit une ligne de process par
taxe/ristourne/etc puis les SP qui vont bien, puis la SP qui
chapeaute le tout (SI il y en a vraiment besoin, par qu'il est
facile d'automatiser ce type de traitement en chaînant les SP d'une
façon transparente).Le nombre de paramètres à passer aux SPs étaient effroyables
(jusqu'à 300 paramètres pour la plus grosse de mémoire).
Ca me parait, là encore, relever d'une erreur de conception liée au §
ci-dessus.
Gné ? Ça devient limite de l'hérésie là… Le jour où je rajoute des
écrans, je dois toucher à ma BdD ? Oo
Si les écrans demandent des données non primitivement renvoyées, oui
- mais c'est la même chose où que se trouve le code: il faut bien
modifier qq chose pour changer le résultat.
Alors il faut pousser le raisonnement à son paroxysme et utiliser
tous les outils dispos, de l'orm à la base olap, en passant par
(sèpulnom) les bases qui s'auto-reconfigurent par (re)design des
flux métiers. Mais le risque du manque de connaissance est là aussi
bien présent parce que ces outils sont tellement généraux qu'ils
demandent des compétences très particulières (et souvent directement
liées au métier-client) lors de leurs configurations.
Je ne fais pas de java, donc je n'ai pas d'opinion sur Hibernate que
je ne connais que de nom; mais je me rappelle qd même avoir lû pas
mal de flammes dessus, notamment chez Pg.
Le seul bémol que j'y mettrais (mais ça n'est pas simple à faire,
surtout quand on a la tête dans le guidon) serait d'évaluer en
profondeur chaque outil afin de restreindre le choix aux "bons", ou
tout du moins aux plus adaptés.
Bien que je ne maîtrise pas ce que permet de telles SP au niveau
sécurité DB, j'imagine assez mal ne pas pouvoir faire ce type de
contrôle au niveau applicatif. Peut-être me trompé-je…
Avec l'apparition de Pg ≥ 9.0 le contrôle est devenu bcp plus fin
(colonnes), il me parait donc logique que la DB s'occupe du contrôle
d'accès.
C'est en partie vrai, mais depuis qq temps on observe une
convergence, à mon avis non-fortuite, entre Pg & Oracle; et il n'y a
pas tant que cela d'autres compétiteurs du même niveau. C'est pour
cela que j'essaye de penser hors des sentiers battus; la portabilité
c'est Tbien dans l'abstrait, mais encore faut-il: * qu'il y ait un
intérêt quelconque à éventuellement switcher,
* qu'il existe un moteur capable de rendre les même services.
* que ladite portabilité ne se fasse pas au détriment des perfs.
Même si N00 ça ne pose pas de PB insoluble (surtout que dans Pg,
une
passé le premier appel qui déclenche la compilation, c'est le
pseudo-code qui est exécuté).
Pas convaincu… J'ai l'exemple d'une de mes applis de gestion
biométriques où les données nominatives n'étaient accessibles que
par les admins du système. Une partie du contrôle des accès aux
colonnes de la db était donc à faire au niveau applicatif !
Développe un peu plus parce que là je ne vois pas le tableau.
Ca n'est point ce que j'avions lû qq posts plus haut, gent
damoiseau!: "Certes, le « SELECT * » n'est pas recommandé. Mais il a
l'avantage de permettre d'être justement indépendant des SDD derrière
: si je modifie ma table source, je n'ai pas à modifier ma requète !"
SIC
Si j'ai besoin de pools et/ou de cache(s), je vais les chercher
individuellement là où ils sont 100% fonctionnels et très
performants, pas dans une soupe où l'on trouve tout et n'importe
quoi - souvent bricolés à la va-vite sur demande pressante des
utilisateurs.
Apparemment mauvaise analyse dûe à une connaissance pas assez
approfondie de la DB utilisée.
Dans ce cas, fais les passer en AGILE ou XP - je ne sais plus lequel
procède par releases rapides, mais c'est un système qui a bcp
d'avantages: release when ready AND tested, puis ajouts de
fonctionnalités par releases, jusqu'à release 1.0
Ha haaaa, la vieille base qu'on ne peut pas toucher - un must du
C'est aussi là que la préparation pêche: soit le client conserve sa
il encaisse *également* les inconvénients qui vont avec, soit il y a
migration et donc création d'une Nlle base.
Là encore, c'est une question d'analyse préalable - prendre un
marché, c'est bien, mais pas s'il doit se transformer en sables
mouvants dès le dev.
Là encore c'est un défaut d'analyse: comment accepter des données
externes alors qu'elles auraient dû se trouver dans la DB?
Pour te donner une idée, même les tailles & positionnements des
mon projet sont stockés dans la DB.
Une fois que c'est fait, on définit une ligne de process par
taxe/ristourne/etc puis les SP qui vont bien, puis la SP qui
chapeaute le tout (SI il y en a vraiment besoin, par qu'il est
facile d'automatiser ce type de traitement en chaînant les SP d'une
façon transparente).
Le nombre de paramètres à passer aux SPs étaient effroyables
(jusqu'à 300 paramètres pour la plus grosse de mémoire).
Ca me parait, là encore, relever d'une erreur de conception liée au §
ci-dessus.
Gné ? Ça devient limite de l'hérésie là… Le jour où je rajoute des
écrans, je dois toucher à ma BdD ? Oo
Si les écrans demandent des données non primitivement renvoyées, oui
- mais c'est la même chose où que se trouve le code: il faut bien
modifier qq chose pour changer le résultat.
Alors il faut pousser le raisonnement à son paroxysme et utiliser
tous les outils dispos, de l'orm à la base olap, en passant par
(sèpulnom) les bases qui s'auto-reconfigurent par (re)design des
flux métiers. Mais le risque du manque de connaissance est là aussi
bien présent parce que ces outils sont tellement généraux qu'ils
demandent des compétences très particulières (et souvent directement
liées au métier-client) lors de leurs configurations.
Je ne fais pas de java, donc je n'ai pas d'opinion sur Hibernate que
je ne connais que de nom; mais je me rappelle qd même avoir lû pas
mal de flammes dessus, notamment chez Pg.
Le seul bémol que j'y mettrais (mais ça n'est pas simple à faire,
surtout quand on a la tête dans le guidon) serait d'évaluer en
profondeur chaque outil afin de restreindre le choix aux "bons", ou
tout du moins aux plus adaptés.
Bien que je ne maîtrise pas ce que permet de telles SP au niveau
sécurité DB, j'imagine assez mal ne pas pouvoir faire ce type de
contrôle au niveau applicatif. Peut-être me trompé-je…
Avec l'apparition de Pg ≥ 9.0 le contrôle est devenu bcp plus fin
(colonnes), il me parait donc logique que la DB s'occupe du contrôle
d'accès.
C'est en partie vrai, mais depuis qq temps on observe une
convergence, à mon avis non-fortuite, entre Pg & Oracle; et il n'y a
pas tant que cela d'autres compétiteurs du même niveau. C'est pour
cela que j'essaye de penser hors des sentiers battus; la portabilité
c'est Tbien dans l'abstrait, mais encore faut-il: * qu'il y ait un
intérêt quelconque à éventuellement switcher,
* qu'il existe un moteur capable de rendre les même services.
* que ladite portabilité ne se fasse pas au détriment des perfs.
Même si N00 ça ne pose pas de PB insoluble (surtout que dans Pg,
une
passé le premier appel qui déclenche la compilation, c'est le
pseudo-code qui est exécuté).
Pas convaincu… J'ai l'exemple d'une de mes applis de gestion
biométriques où les données nominatives n'étaient accessibles que
par les admins du système. Une partie du contrôle des accès aux
colonnes de la db était donc à faire au niveau applicatif !
Développe un peu plus parce que là je ne vois pas le tableau.
Ca n'est point ce que j'avions lû qq posts plus haut, gent
damoiseau!: "Certes, le « SELECT * » n'est pas recommandé. Mais il a
l'avantage de permettre d'être justement indépendant des SDD derrière
: si je modifie ma table source, je n'ai pas à modifier ma requète !"
SIC
Si j'ai besoin de pools et/ou de cache(s), je vais les chercher
individuellement là où ils sont 100% fonctionnels et très
performants, pas dans une soupe où l'on trouve tout et n'importe
quoi - souvent bricolés à la va-vite sur demande pressante des
utilisateurs.
Apparemment mauvaise analyse dûe à une connaissance pas assez
approfondie de la DB utilisée.
Dans ce cas, fais les passer en AGILE ou XP - je ne sais plus lequel
procède par releases rapides, mais c'est un système qui a bcp
d'avantages: release when ready AND tested, puis ajouts de
fonctionnalités par releases, jusqu'à release 1.0
Ha haaaa, la vieille base qu'on ne peut pas toucher - un must du
C'est aussi là que la préparation pêche: soit le client conserve sa
il encaisse *également* les inconvénients qui vont avec, soit il y a
migration et donc création d'une Nlle base.
Là encore, c'est une question d'analyse préalable - prendre un
marché, c'est bien, mais pas s'il doit se transformer en sables
mouvants dès le dev.
Là encore c'est un défaut d'analyse: comment accepter des données
externes alors qu'elles auraient dû se trouver dans la DB?
Pour te donner une idée, même les tailles & positionnements des
mon projet sont stockés dans la DB.
Une fois que c'est fait, on définit une ligne de process par
taxe/ristourne/etc puis les SP qui vont bien, puis la SP qui
chapeaute le tout (SI il y en a vraiment besoin, par qu'il est
facile d'automatiser ce type de traitement en chaînant les SP d'une
façon transparente).Le nombre de paramètres à passer aux SPs étaient effroyables
(jusqu'à 300 paramètres pour la plus grosse de mémoire).
Ca me parait, là encore, relever d'une erreur de conception liée au §
ci-dessus.
Gné ? Ça devient limite de l'hérésie là… Le jour où je rajoute des
écrans, je dois toucher à ma BdD ? Oo
Si les écrans demandent des données non primitivement renvoyées, oui
- mais c'est la même chose où que se trouve le code: il faut bien
modifier qq chose pour changer le résultat.
Alors il faut pousser le raisonnement à son paroxysme et utiliser
tous les outils dispos, de l'orm à la base olap, en passant par
(sèpulnom) les bases qui s'auto-reconfigurent par (re)design des
flux métiers. Mais le risque du manque de connaissance est là aussi
bien présent parce que ces outils sont tellement généraux qu'ils
demandent des compétences très particulières (et souvent directement
liées au métier-client) lors de leurs configurations.
Je ne fais pas de java, donc je n'ai pas d'opinion sur Hibernate que
je ne connais que de nom; mais je me rappelle qd même avoir lû pas
mal de flammes dessus, notamment chez Pg.
Le seul bémol que j'y mettrais (mais ça n'est pas simple à faire,
surtout quand on a la tête dans le guidon) serait d'évaluer en
profondeur chaque outil afin de restreindre le choix aux "bons", ou
tout du moins aux plus adaptés.
> Même si N00 ça ne pose pas de PB insoluble (surtout que d ans Pg,
> une
fois
> passé le premier appel qui déclenche la compilation, c'est le
> pseudo-code qui est exécuté).
Certes, mais 300 cas centralisés dans 1 seule SP (sachant que le max imum
toléré en développement normal est 10), c'est de l'hé résie et ça pue Ã
plein nez le truc inmaintenableâ¦
L'application en question gére la délivrance de passports biom étriques.
Les champs nominatifs de la base (nom, prénom, adresse, n° sà ©cuâ¦) sont
accessibles uniquement aux administrateurs et aux experts biométries,
pour des raisons légales (style la CNIL chez nous).
Les personnes lambda n'ont accès qu'aux données banalisées (n°
d'enregistrement, bureau d'enregistrementâ¦).
Je peux faire un « SELECT * » mais accéder aux donnée s par un «
row['col1'] » au lieu de « row[0] ».
En PHP, c'est la différence entre « fetch_row » et « fetch_assoc ».
Au final, je conserve un code évolutif (l'ajout de colonne ne pertur bent
pas mon code), sans avoir de problème d'ordre.
Avec Hibernate, c'est encore plus simple, parce qu'il génère to ut seul
la liste des colonnes qui l'intéresse !
En gérant celle en lazy-loading, etcâ¦
> Apparemment mauvaise analyse dûe à une connaissance pas assez
> approfondie de la DB utilisée.
Non, juste que la base avait des tables à plus de 400 colonnes, et d es
critères de filtres sur 100 ou 150 critères.
> Dans ce cas, fais les passer en AGILE ou XP - je ne sais plus lequel
> procède par releases rapides, mais c'est un système qui a bc p
> d'avantages: release when ready AND tested, puis ajouts de
> fonctionnalités par releases, jusqu'à release 1.0
Le soucis n'était pas d'ajouter de nouvelles fonctionnalités, m ais de
savoir dans le détail comment les SP étaient gaulées, afin de limiter
les duplications, de cerner les régressions possiblesâ¦
Quand tu as des centaines de SP devant toi et que tu dois implémente r «
chercher les X qui contiennent Y et les trier par Z », t'as 2 soluti ons :
â soit tu passes du temps à dépiauter tes SP dans tous les sens pour
voir si une ne ferait pas déjà les ¾ du boulot (du genre «
SPChercherXContenantY ») et éviter ainsi la duplication des SP
â soit tu ne cherches pas à comprendre et tu fais directemen t ta SP «
SPChercherXContenantYTrieParZ », quitte à dupliquer et exploser encore
plus la quantité de SP
Idem lorsqu'on devait ajouter une colonne, lesquelles des centaines de
SP est à vérifier et/ou corriger ?
> Ha haaaa, la vieille base qu'on ne peut pas toucher - un must du
classique!
> C'est aussi là que la préparation pêche: soit le client conserve sa
base et
> il encaisse *également* les inconvénients qui vont avec, soit il y a
> migration et donc création d'une Nlle base.
On lui avait bien fait remarqué que la base n'utilisait peu ou pas l es
clefs étrangères, étaient mal indexées ou conçue s.
On avait même réussi à poser une clause de non-engagement sur les perfs.
Le soucis est qu'on s'est laissé mangé par l'apparente facilit é des
règles métier. Au final, elles n'étaient pas très com pliquées (si la
transaction va de X à Y avec une carte de la banque Z, donner tant à A1,
tant à A2, tant à A3â¦).
On a juste bien déchanté quand on s'est rendu compte de la comp lexité
des requêtes derrière, d'autant plus qu'on avait la contrainte de tout
faire en SP.
Et on a encore plus déchanté quand le client, après avoir fourni un
fichier de 2ko de règles de gestion dans l'appel d'offre, nous a fou rni
le service externe réel, qui nous balançait des fichiers de 200 Mo et
quelques 80.000 règles de répartition !
On n'a souvent pas assez de temps pour éponger tous les problèm es
techniques potentiels, surtout ceux à plus ou moins long terme.
Même avec des mois d'analyse, une doc de 1.000 pages reste forcà ©ment
avec des piègesâ¦
D'autant plus que si dès qu'on avait un risque potentiel on refusait un
appel d'offre, ça fait belle lurette qu'on aurait plus de projet⠦
> Là encore c'est un défaut d'analyse: comment accepter des don nées
> externes alors qu'elles auraient dû se trouver dans la DB?
Les données provenaient de systèmes externes et/ou de sous-syst èmes,
sous la forme de web-services.
Non.
En gros, une transaction comporte 300 caractéristiques, comme
l'émetteur, l'origine, la destination, le type de carte, le montant â¦
Et en entrée on avait une conf avec quasiment autant de paramèt res, qui
disait plus ou moins « si une transaction a cette gueule, elle se
décompose en X sous-transactions », chaque sous-transaction à ©tant
elle-même représentée par des centaines de champs et pouva nt être soit
un montant fixe soit un pourcentage du montant de départ.
Et le système n'était qu'un gros calculateur du type « sou s-transactions
= f(transaction, conf) ».
Le gros soucis est que « f() » n'est pas linéaire⦠« f([a, b], c) !=
[f(a, c), f(b, c)] ». On ne peut pas faire de traitement par lots, m ais
uniquement transaction par transaction.
> Alors il faut pousser le raisonnement à son paroxysme et utiliser
> tous les outils dispos, de l'orm à la base olap, en passant par
> (sèpulnom) les bases qui s'auto-reconfigurent par (re)design des
> flux métiers. Mais le risque du manque de connaissance est là aussi
> bien présent parce que ces outils sont tellement générau x qu'ils
> demandent des compétences très particulières (et souvent directement
> liées au métier-client) lors de leurs configurations.
Tout est une histoire de mesure.
Tombé dans l'OLAP, c'est quand même le canon de 14 pour tuer un
moustique. La mitrailleuse lourde est déjà bien suffisante et p ossède
assez de marge pour descendre une marmotte si le besoin s'en fait sentir.
> Même si N=300 ça ne pose pas de PB insoluble (surtout que d ans Pg,
> une
fois
> passé le premier appel qui déclenche la compilation, c'est le
> pseudo-code qui est exécuté).
Certes, mais 300 cas centralisés dans 1 seule SP (sachant que le max imum
toléré en développement normal est 10), c'est de l'hé résie et ça pue Ã
plein nez le truc inmaintenableâ¦
L'application en question gére la délivrance de passports biom étriques.
Les champs nominatifs de la base (nom, prénom, adresse, n° sà ©cuâ¦) sont
accessibles uniquement aux administrateurs et aux experts biométries,
pour des raisons légales (style la CNIL chez nous).
Les personnes lambda n'ont accès qu'aux données banalisées (n°
d'enregistrement, bureau d'enregistrementâ¦).
Je peux faire un « SELECT * » mais accéder aux donnée s par un «
row['col1'] » au lieu de « row[0] ».
En PHP, c'est la différence entre « fetch_row » et « fetch_assoc ».
Au final, je conserve un code évolutif (l'ajout de colonne ne pertur bent
pas mon code), sans avoir de problème d'ordre.
Avec Hibernate, c'est encore plus simple, parce qu'il génère to ut seul
la liste des colonnes qui l'intéresse !
En gérant celle en lazy-loading, etcâ¦
> Apparemment mauvaise analyse dûe à une connaissance pas assez
> approfondie de la DB utilisée.
Non, juste que la base avait des tables à plus de 400 colonnes, et d es
critères de filtres sur 100 ou 150 critères.
> Dans ce cas, fais les passer en AGILE ou XP - je ne sais plus lequel
> procède par releases rapides, mais c'est un système qui a bc p
> d'avantages: release when ready AND tested, puis ajouts de
> fonctionnalités par releases, jusqu'à release 1.0
Le soucis n'était pas d'ajouter de nouvelles fonctionnalités, m ais de
savoir dans le détail comment les SP étaient gaulées, afin de limiter
les duplications, de cerner les régressions possiblesâ¦
Quand tu as des centaines de SP devant toi et que tu dois implémente r «
chercher les X qui contiennent Y et les trier par Z », t'as 2 soluti ons :
â soit tu passes du temps à dépiauter tes SP dans tous les sens pour
voir si une ne ferait pas déjà les ¾ du boulot (du genre «
SPChercherXContenantY ») et éviter ainsi la duplication des SP
â soit tu ne cherches pas à comprendre et tu fais directemen t ta SP «
SPChercherXContenantYTrieParZ », quitte à dupliquer et exploser encore
plus la quantité de SP
Idem lorsqu'on devait ajouter une colonne, lesquelles des centaines de
SP est à vérifier et/ou corriger ?
> Ha haaaa, la vieille base qu'on ne peut pas toucher - un must du
classique!
> C'est aussi là que la préparation pêche: soit le client conserve sa
base et
> il encaisse *également* les inconvénients qui vont avec, soit il y a
> migration et donc création d'une Nlle base.
On lui avait bien fait remarqué que la base n'utilisait peu ou pas l es
clefs étrangères, étaient mal indexées ou conçue s.
On avait même réussi à poser une clause de non-engagement sur les perfs.
Le soucis est qu'on s'est laissé mangé par l'apparente facilit é des
règles métier. Au final, elles n'étaient pas très com pliquées (si la
transaction va de X à Y avec une carte de la banque Z, donner tant à A1,
tant à A2, tant à A3â¦).
On a juste bien déchanté quand on s'est rendu compte de la comp lexité
des requêtes derrière, d'autant plus qu'on avait la contrainte de tout
faire en SP.
Et on a encore plus déchanté quand le client, après avoir fourni un
fichier de 2ko de règles de gestion dans l'appel d'offre, nous a fou rni
le service externe réel, qui nous balançait des fichiers de 200 Mo et
quelques 80.000 règles de répartition !
On n'a souvent pas assez de temps pour éponger tous les problèm es
techniques potentiels, surtout ceux à plus ou moins long terme.
Même avec des mois d'analyse, une doc de 1.000 pages reste forcà ©ment
avec des piègesâ¦
D'autant plus que si dès qu'on avait un risque potentiel on refusait un
appel d'offre, ça fait belle lurette qu'on aurait plus de projet⠦
> Là encore c'est un défaut d'analyse: comment accepter des don nées
> externes alors qu'elles auraient dû se trouver dans la DB?
Les données provenaient de systèmes externes et/ou de sous-syst èmes,
sous la forme de web-services.
Non.
En gros, une transaction comporte 300 caractéristiques, comme
l'émetteur, l'origine, la destination, le type de carte, le montant â¦
Et en entrée on avait une conf avec quasiment autant de paramèt res, qui
disait plus ou moins « si une transaction a cette gueule, elle se
décompose en X sous-transactions », chaque sous-transaction à ©tant
elle-même représentée par des centaines de champs et pouva nt être soit
un montant fixe soit un pourcentage du montant de départ.
Et le système n'était qu'un gros calculateur du type « sou s-transactions
= f(transaction, conf) ».
Le gros soucis est que « f() » n'est pas linéaire⦠« f([a, b], c) !=
[f(a, c), f(b, c)] ». On ne peut pas faire de traitement par lots, m ais
uniquement transaction par transaction.
> Alors il faut pousser le raisonnement à son paroxysme et utiliser
> tous les outils dispos, de l'orm à la base olap, en passant par
> (sèpulnom) les bases qui s'auto-reconfigurent par (re)design des
> flux métiers. Mais le risque du manque de connaissance est là aussi
> bien présent parce que ces outils sont tellement générau x qu'ils
> demandent des compétences très particulières (et souvent directement
> liées au métier-client) lors de leurs configurations.
Tout est une histoire de mesure.
Tombé dans l'OLAP, c'est quand même le canon de 14 pour tuer un
moustique. La mitrailleuse lourde est déjà bien suffisante et p ossède
assez de marge pour descendre une marmotte si le besoin s'en fait sentir.
> Même si N00 ça ne pose pas de PB insoluble (surtout que d ans Pg,
> une
fois
> passé le premier appel qui déclenche la compilation, c'est le
> pseudo-code qui est exécuté).
Certes, mais 300 cas centralisés dans 1 seule SP (sachant que le max imum
toléré en développement normal est 10), c'est de l'hé résie et ça pue Ã
plein nez le truc inmaintenableâ¦
L'application en question gére la délivrance de passports biom étriques.
Les champs nominatifs de la base (nom, prénom, adresse, n° sà ©cuâ¦) sont
accessibles uniquement aux administrateurs et aux experts biométries,
pour des raisons légales (style la CNIL chez nous).
Les personnes lambda n'ont accès qu'aux données banalisées (n°
d'enregistrement, bureau d'enregistrementâ¦).
Je peux faire un « SELECT * » mais accéder aux donnée s par un «
row['col1'] » au lieu de « row[0] ».
En PHP, c'est la différence entre « fetch_row » et « fetch_assoc ».
Au final, je conserve un code évolutif (l'ajout de colonne ne pertur bent
pas mon code), sans avoir de problème d'ordre.
Avec Hibernate, c'est encore plus simple, parce qu'il génère to ut seul
la liste des colonnes qui l'intéresse !
En gérant celle en lazy-loading, etcâ¦
> Apparemment mauvaise analyse dûe à une connaissance pas assez
> approfondie de la DB utilisée.
Non, juste que la base avait des tables à plus de 400 colonnes, et d es
critères de filtres sur 100 ou 150 critères.
> Dans ce cas, fais les passer en AGILE ou XP - je ne sais plus lequel
> procède par releases rapides, mais c'est un système qui a bc p
> d'avantages: release when ready AND tested, puis ajouts de
> fonctionnalités par releases, jusqu'à release 1.0
Le soucis n'était pas d'ajouter de nouvelles fonctionnalités, m ais de
savoir dans le détail comment les SP étaient gaulées, afin de limiter
les duplications, de cerner les régressions possiblesâ¦
Quand tu as des centaines de SP devant toi et que tu dois implémente r «
chercher les X qui contiennent Y et les trier par Z », t'as 2 soluti ons :
â soit tu passes du temps à dépiauter tes SP dans tous les sens pour
voir si une ne ferait pas déjà les ¾ du boulot (du genre «
SPChercherXContenantY ») et éviter ainsi la duplication des SP
â soit tu ne cherches pas à comprendre et tu fais directemen t ta SP «
SPChercherXContenantYTrieParZ », quitte à dupliquer et exploser encore
plus la quantité de SP
Idem lorsqu'on devait ajouter une colonne, lesquelles des centaines de
SP est à vérifier et/ou corriger ?
> Ha haaaa, la vieille base qu'on ne peut pas toucher - un must du
classique!
> C'est aussi là que la préparation pêche: soit le client conserve sa
base et
> il encaisse *également* les inconvénients qui vont avec, soit il y a
> migration et donc création d'une Nlle base.
On lui avait bien fait remarqué que la base n'utilisait peu ou pas l es
clefs étrangères, étaient mal indexées ou conçue s.
On avait même réussi à poser une clause de non-engagement sur les perfs.
Le soucis est qu'on s'est laissé mangé par l'apparente facilit é des
règles métier. Au final, elles n'étaient pas très com pliquées (si la
transaction va de X à Y avec une carte de la banque Z, donner tant à A1,
tant à A2, tant à A3â¦).
On a juste bien déchanté quand on s'est rendu compte de la comp lexité
des requêtes derrière, d'autant plus qu'on avait la contrainte de tout
faire en SP.
Et on a encore plus déchanté quand le client, après avoir fourni un
fichier de 2ko de règles de gestion dans l'appel d'offre, nous a fou rni
le service externe réel, qui nous balançait des fichiers de 200 Mo et
quelques 80.000 règles de répartition !
On n'a souvent pas assez de temps pour éponger tous les problèm es
techniques potentiels, surtout ceux à plus ou moins long terme.
Même avec des mois d'analyse, une doc de 1.000 pages reste forcà ©ment
avec des piègesâ¦
D'autant plus que si dès qu'on avait un risque potentiel on refusait un
appel d'offre, ça fait belle lurette qu'on aurait plus de projet⠦
> Là encore c'est un défaut d'analyse: comment accepter des don nées
> externes alors qu'elles auraient dû se trouver dans la DB?
Les données provenaient de systèmes externes et/ou de sous-syst èmes,
sous la forme de web-services.
Non.
En gros, une transaction comporte 300 caractéristiques, comme
l'émetteur, l'origine, la destination, le type de carte, le montant â¦
Et en entrée on avait une conf avec quasiment autant de paramèt res, qui
disait plus ou moins « si une transaction a cette gueule, elle se
décompose en X sous-transactions », chaque sous-transaction à ©tant
elle-même représentée par des centaines de champs et pouva nt être soit
un montant fixe soit un pourcentage du montant de départ.
Et le système n'était qu'un gros calculateur du type « sou s-transactions
= f(transaction, conf) ».
Le gros soucis est que « f() » n'est pas linéaire⦠« f([a, b], c) !=
[f(a, c), f(b, c)] ». On ne peut pas faire de traitement par lots, m ais
uniquement transaction par transaction.
> Alors il faut pousser le raisonnement à son paroxysme et utiliser
> tous les outils dispos, de l'orm à la base olap, en passant par
> (sèpulnom) les bases qui s'auto-reconfigurent par (re)design des
> flux métiers. Mais le risque du manque de connaissance est là aussi
> bien présent parce que ces outils sont tellement générau x qu'ils
> demandent des compétences très particulières (et souvent directement
> liées au métier-client) lors de leurs configurations.
Tout est une histoire de mesure.
Tombé dans l'OLAP, c'est quand même le canon de 14 pour tuer un
moustique. La mitrailleuse lourde est déjà bien suffisante et p ossède
assez de marge pour descendre une marmotte si le besoin s'en fait sentir.
Je rajoute "de base" à mauvaise analyse: quand on se retrouve avec des tables
et des filtres aussi gros c'est que la conception de base s'est fourrée le
doigt dans l'œil jusqu'au trognon. (je parle de l'antérieur).
Effectivement, ça n'est gérable que par du middleware.
Là n'était pas le PB, il se trouve dans la phrase au-dessus: comment
avez-vous pu accepter de reprendre cette DB telle quelle?!;
je ne parle
même plus des tables à 400 colonnes, mais bien des mauvaises indexations; c'est
typiquement symptomatique d'un mille-feuille jamais retouché (à moins que les
concepteurs de base n'aient *vraiment* été des burnes, ce qui existe
malheureusement).
Wai, ça revient à l'histoire de mon pote: on vous a refilé le truc dont
personne ne voulait en cachant bien la merde au chat.
D'ailleurs, je me demande si ça ne serait pas une idée de site pro à monter
ça: un répertoire des boîtes qui se foutent du monde rapport à leurs demandes
impossibles...
J'entends bien, mais là encore les défauts de base de la DB étaient
rédhibitoires.
Les données provenaient de systèmes externes et/ou de sous-systèmes,
sous la forme de web-services.
C'est plus une usine à gaz mais un complexe pétrolier au grand complet ton
histoire :(
Tout est une histoire de mesure.
Tombé dans l'OLAP, c'est quand même le canon de 14 pour tuer un
moustique. La mitrailleuse lourde est déjà bien suffisante et possède
assez de marge pour descendre une marmotte si le besoin s'en fait sentir.
Ben pas vraiment, vu comment tu décris la chose (d'un autre monde:)
OLAP, middleware(s) et le reste qui va bien avec - mais même comme ça, ça
reste du monstrueux construit sur une base inacceptable (la DB).
Ca permet aussi n'importe quelle gymnastique dans le cadre du reporting sans
trop d'efforts à fournir.
Les trucs que je ne comprends pas c'est pourquoi vous avez pris l'affaire
sachant que la base était pourrie (principe de la chaîne), ni cassé le
contrat lorsque le client vous a avoué que c'était en fait 80k règles qu'il
fallait appliquer?
Et pourquoi à la base les concepteurs DB n'ont pas mis un véto absolu, au vu de
l'état de la base à reprendre?
Mais remarquons le bon côté de la chose: en se faisant bien mettre une fois
comme celle-là on reste normalement vacciné un long moment après ;-)
Je rajoute "de base" à mauvaise analyse: quand on se retrouve avec des tables
et des filtres aussi gros c'est que la conception de base s'est fourrée le
doigt dans l'œil jusqu'au trognon. (je parle de l'antérieur).
Effectivement, ça n'est gérable que par du middleware.
Là n'était pas le PB, il se trouve dans la phrase au-dessus: comment
avez-vous pu accepter de reprendre cette DB telle quelle?!;
je ne parle
même plus des tables à 400 colonnes, mais bien des mauvaises indexations; c'est
typiquement symptomatique d'un mille-feuille jamais retouché (à moins que les
concepteurs de base n'aient *vraiment* été des burnes, ce qui existe
malheureusement).
Wai, ça revient à l'histoire de mon pote: on vous a refilé le truc dont
personne ne voulait en cachant bien la merde au chat.
D'ailleurs, je me demande si ça ne serait pas une idée de site pro à monter
ça: un répertoire des boîtes qui se foutent du monde rapport à leurs demandes
impossibles...
J'entends bien, mais là encore les défauts de base de la DB étaient
rédhibitoires.
Les données provenaient de systèmes externes et/ou de sous-systèmes,
sous la forme de web-services.
C'est plus une usine à gaz mais un complexe pétrolier au grand complet ton
histoire :(
Tout est une histoire de mesure.
Tombé dans l'OLAP, c'est quand même le canon de 14 pour tuer un
moustique. La mitrailleuse lourde est déjà bien suffisante et possède
assez de marge pour descendre une marmotte si le besoin s'en fait sentir.
Ben pas vraiment, vu comment tu décris la chose (d'un autre monde:)
OLAP, middleware(s) et le reste qui va bien avec - mais même comme ça, ça
reste du monstrueux construit sur une base inacceptable (la DB).
Ca permet aussi n'importe quelle gymnastique dans le cadre du reporting sans
trop d'efforts à fournir.
Les trucs que je ne comprends pas c'est pourquoi vous avez pris l'affaire
sachant que la base était pourrie (principe de la chaîne), ni cassé le
contrat lorsque le client vous a avoué que c'était en fait 80k règles qu'il
fallait appliquer?
Et pourquoi à la base les concepteurs DB n'ont pas mis un véto absolu, au vu de
l'état de la base à reprendre?
Mais remarquons le bon côté de la chose: en se faisant bien mettre une fois
comme celle-là on reste normalement vacciné un long moment après ;-)
Je rajoute "de base" à mauvaise analyse: quand on se retrouve avec des tables
et des filtres aussi gros c'est que la conception de base s'est fourrée le
doigt dans l'œil jusqu'au trognon. (je parle de l'antérieur).
Effectivement, ça n'est gérable que par du middleware.
Là n'était pas le PB, il se trouve dans la phrase au-dessus: comment
avez-vous pu accepter de reprendre cette DB telle quelle?!;
je ne parle
même plus des tables à 400 colonnes, mais bien des mauvaises indexations; c'est
typiquement symptomatique d'un mille-feuille jamais retouché (à moins que les
concepteurs de base n'aient *vraiment* été des burnes, ce qui existe
malheureusement).
Wai, ça revient à l'histoire de mon pote: on vous a refilé le truc dont
personne ne voulait en cachant bien la merde au chat.
D'ailleurs, je me demande si ça ne serait pas une idée de site pro à monter
ça: un répertoire des boîtes qui se foutent du monde rapport à leurs demandes
impossibles...
J'entends bien, mais là encore les défauts de base de la DB étaient
rédhibitoires.
Les données provenaient de systèmes externes et/ou de sous-systèmes,
sous la forme de web-services.
C'est plus une usine à gaz mais un complexe pétrolier au grand complet ton
histoire :(
Tout est une histoire de mesure.
Tombé dans l'OLAP, c'est quand même le canon de 14 pour tuer un
moustique. La mitrailleuse lourde est déjà bien suffisante et possède
assez de marge pour descendre une marmotte si le besoin s'en fait sentir.
Ben pas vraiment, vu comment tu décris la chose (d'un autre monde:)
OLAP, middleware(s) et le reste qui va bien avec - mais même comme ça, ça
reste du monstrueux construit sur une base inacceptable (la DB).
Ca permet aussi n'importe quelle gymnastique dans le cadre du reporting sans
trop d'efforts à fournir.
Les trucs que je ne comprends pas c'est pourquoi vous avez pris l'affaire
sachant que la base était pourrie (principe de la chaîne), ni cassé le
contrat lorsque le client vous a avoué que c'était en fait 80k règles qu'il
fallait appliquer?
Et pourquoi à la base les concepteurs DB n'ont pas mis un véto absolu, au vu de
l'état de la base à reprendre?
Mais remarquons le bon côté de la chose: en se faisant bien mettre une fois
comme celle-là on reste normalement vacciné un long moment après ;-)
