Piratage Mysql
Frédéric ZULIAN
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
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20110915204...@zulian.com
Jean-Yves F. Barbier
> Je viens de me faire pirater ma base de données MYSQL.
> « exploit » utilise win NT 5 avec HAVIJ v1.15.
Celui-là est un délicat et sans doute pas vraiment un cracker.
> 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 ?
Rien ne devrait être mis en Sce sans utiliser au minimum les divers outils de
vérification/pénétration qu'on trouve sur le net - sans compter mysql qui est
déjà une belle daube de base.
Et normalement le traitement ne devrait jamais être externe, mais inclus dans
la DB (procédures stockées).
Donc pour ton appli, à moins de la réécrire correctement, y'a pas vraiment de
solution.
--
I've run DOOM more in the last few days than I have the last few
months. I just love debugging ;-)
(Linus Torvalds)
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
Le 15/09/2011 22:50, Frédéric ZULIAN a écrit :
> Il a récupéré toute la base : Identifiant et mdp.
root // P@ssw0rd ?
> Du coût je n'ose plus redémarrer mon serveur.
>
> Une idée de la parade ?
Déjà il faudrait savoir par où il est passé.
Ce n'est peut-être pas MySQL qui a été hacké, mais un soft annexe
connecté à MySQL.
Sinon au pif :
— MySQL et/ou PHPMyAdmin sont-ils en DMZ ?
— Chaque application MySQL a-t-elle son propre compte d'accès, avec un
pass suffisamment robuste et sans aucun droit autre que sur la base
concernée et sans droit admin ?
Le soucis vient peut-être de là déjà…
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOcmiDAAoJEK8zQvxDY4P9N5wH/3OkNcB0PR1+uUzuN7EQYXWF
F9oP4G5FoEXICD10F0OzfrJOvGLFymbl9aMe7/eM+9z0L0QDh4Vg+Xucj3U3n6iw
EFxbzCFOEmHlXS5hY0h4YMaXm9VVLdX+SWXc3pYiWAqV6+NCBaFcMZls5i7PzuDc
icYN9dQ9zJ429X9JBhae8a38yRzGc234ErTdcKKRo0Vq7Hn9ELgxW56Eoqv/TeDq
1BLPNujqzDSfHsXuznG86J5jlUojeMv+JA7DO58rsT0M9a6IUc9n3VuXStjDxejH
yxNRw/DeG0HDAcehFjgo2QVyiv0AhD0Frgrh6Ods3/eeuSusJXzh6JGUyDHD9yw=
=7OTE
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/4e726889$0$7290$426a...@news.free.fr
Jean-Michel OLTRA
Bonjour,
Le jeudi 15 septembre 2011, Frédéric ZULIAN a écrit...
> 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.
Les logs du serveur sont ils activés ? Pour retrouver la requête
effectuée. En prod, il y a peu de chances …
Sinon, si tu as quelque chose sur lui (sa machine), tu pourrais
retrouver les pages qu'il a chargées (dans les logs du serveur ouèbe),
et tenter de lancer dessus un outil de pénétration sql.
--
jm
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20110915222607.GB11319@espinasse
Frédéric Massot
>
> 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.
a eu plusieurs alertes de sécurité les mois passés. Il faut protéger
PHPMyAdmin par un .htaccess, ou mieux ne pas autorisé les accès extérieurs.
A+.
--
==============================================
| FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto:fred...@juliana-multimedia.com |
===========================Debian=GNU/Linux===
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Lucas
Si tu veux un réel coup de main pour remédier à ce problème il va falloir beaucoup plus d'information.
Il est hébergé chez toi ou en data-center ?
Quelle sont les services fonctionnant dessus ? (Apache, MySQL, SSH, Autres ...)
Qu'est ce qui tourné sur ton serveur Apache (Wordpress, ...) ?
Avait tu un firewall ?
Bref, Un max d'info pour que l'on puisse t'orienter.
L.
Frédéric ZULIAN
> Hash: SHA1
>
> Le 15/09/2011 22:50, Frédéric ZULIAN a écrit :
> > Il a récupéré toute la base : Identifiant et mdp.
>
> root // P@ssw0rd ?
et tu choisis ce que tu veux.
> Ce n'est peut-être pas MySQL qui a été hacké,
> connecté à MySQL.
>
> Sinon au pif :
Oui, pourquoi c'est MAL ?
> ??? Chaque application MySQL a-t-elle son propre compte d'accès, avec un
> concernée et sans droit admin ?
viennent de la.
Le soft te propose les fichiers à lire, tu clicques et hop les
identifiants et mdp défilent sur ton écran.
--
Frédéric
F1SXO
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Frédéric ZULIAN
>
> Si tu veux un réel coup de main pour remédier à ce problème il va falloir
> beaucoup plus d'information.
> Il est hébergé chez toi ou en data-center ?
> ...)
Hack de Mysql :
http://www.xxxxx.be/winedowze/1.29/index.php?page=home&com=%2760
SELECT auteur, titre, date, contenu, icon FROM live_news WHERE id = '60;
You have an error in your SQL syntax; check the manual that corresponds
to your MySQL server version for the right syntax to use near ''60' at
line 1
Passage dans "HAVIJ" et hop on récupére tout ce que l'on veut.
> Qu'est ce qui tourné sur ton serveur Apache (Wordpress, ...) ?
> Avait tu un firewall ?
80 8080 22 442 5555 3306
> Bref, Un max d'info pour que l'on puisse t'orienter.
>
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
> Non, Je viens de me hacker. Le soft scanne le tout
> et tu choisis ce que tu veux.
>
>> > Ce n'est peut-être pas MySQL qui a été hacké,
> Il utilise une appli win "HAVIJ" qui hacke MySQL
Il se base sur les faiblesses des applications web autour de MySQL, pas
de celles de MySQL directement.
>> > ??? MySQL et/ou PHPMyAdmin sont-ils en DMZ ?
> Oui, pourquoi c'est MAL ?
Les 2 doivent absoluement être mis au mieux derrière un VPN ou un tunnel
SSH, au pire bien sécurisés avec des .htaccess ou autres.
> Je vais mettre des mdp plus robuste mais je ne pense pas que le prb
> viennent de la.
ta base sans avoir d'accès au MySQL.
Mais ça, tant que PHP vivra…
Une « parade » possible est de limiter au maximum les droits des comptes
utilisateurs MySQL.
Un compte par utilisateur et par base de données, des droits
ultra-limités (select / update / delete suffisent généralement), etc.
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
YF0Awyf9nBCvSk3cFHdpzT5OMSwYDxzfj75fFknud2BPd1FiQUVLdPBenY5x23QX
Os+s5DB836OSYtTMu37zAyS82kVgvn3JTMq9WCJP+bIOVc6Cn1B37kI/TdJkITPM
qhrtVPOiqZZhk/955zr3R7MgxtMxHc9V1nLp2MoWTry5Hl9t7+itsNONf0uGMXNT
fWr+fI6QBhhMjuWqLMvM2ClgkrYdMvyK4p6995844AYMi/52p8qdQ6w7WjKh/AmD
aaNeIX1L/ieAZI6Xp851Py7oH0m1mHJt03quMlO3HlnUG5YYp2kQahOhp1xjfY4=
=PlkW
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Jean-Yves F. Barbier
...
> HAVIJ nécessite un site web non sécurisé pour fonctionner.
> Il se base sur les faiblesses des applications web autour de MySQL, pas
> de celles de MySQL directement.
ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p3306)
...
> Non effectivement, HAVIJ fonctionne par injection SQL et peut accéder à
> ta base sans avoir d'accès au MySQL.
> Mais ça, tant que PHP vivra…
ça n'est pas tout à fait vrai: disons plutôt tant que les programmeurs php
ne contrôleront correctement ni leurs morceaux de code ni les droits des
fichiers & directories.
> Une « parade » possible est de limiter au maximum les droits des comptes
> utilisateurs MySQL.
> Un compte par utilisateur et par base de données, des droits
> ultra-limités (select / update / delete suffisent généralement), etc.
Ajoutons: un escaping systématique de toutes les données envoyées vers la DB.
Mais au risque de me répéter, la meilleure parade reste d'inclure le code
"actif" dans la DB (procs stockées); mais je doute qu'à ce jour ce soit facile
(voire même possible à 100%) avec mysql.
--
Quid me anxius sum?
[ What? Me, worry? ]
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20110917003...@anubis.defcon1
Aéris
Hash: SHA1
Le 17/09/2011 00:00, Frédéric ZULIAN a écrit :
> Hack de Mysql :
Ce n'est pas un hack de MySQL, mais une injection SQL d'une de tes
applications web.
> http://www.xxxxx.be/winedowze/1.29/index.php?page=home&com=%2760
> SELECT auteur, titre, date, contenu, icon FROM live_news WHERE id = '60;
> You have an error in your SQL syntax; check the manual that corresponds
> to your MySQL server version for the right syntax to use near ''60' at
> line 1
Voila la faille, ta requète SQL n'est pas protégée contre les injections.
La variable « com » est directement concaténée sans contrôle et sans
échappement à un morceau de SQL, ici apparement
'SELECT auteur, titre, date, contenu, icon FROM live_news WHERE id = '
+ $_GET['com']
Tant que « com » est un nombre, pas de soucis…
SELECT auteur, titre, date, contenu, icon FROM live_news WHERE id = 60
Si « com » devient quelque chose de plus malsain, comme
60+UNION+ALL+SELECT+1%2C+2%2C+3%2C+4%2C+5+FROM+mysql.help_topic+WHERE+1+%3D+1
Boom…
SELECT auteur, titre, date, contenu, icon
FROM live_news
WHERE id = 60
UNION ALL
SELECT 1, 2, 3, 4, 5
FROM mysql.help_topic
WHERE 1 = 1
Et je te dump toute ta table mysql.help_topic…
HAVIJ est juste là pour automatiser l'injection et la remontée des
données des tables.
C'est ton appli qui est merdique au possible (en même temps, avec du
PHP…), pas MySQL sur ce coup-ci.
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOc8yzAAoJEK8zQvxDY4P98BkH/i7KHpOwSZZBNX1jIDBeUTGL
MbqMfP2fJjt3GvCt3oL26cDtCnS/mdERc5nSbcB6pw5lXnZyH16DMM5OaHiMlLiI
xyiyNdlHDkLfE3Xu+b+AzoU8MbWmdC06oCnAmAz3Xdy6hf1CKoVp2z+6nIMyJbWh
g5QannBxgaUQ/2pOq0W7wITkyV2r9J2CvDkeM1/BbuQ33ob9B91VuvnQETpQyV06
Yvx6ZWSDz6cDrP/XZgOtHgKELwKhceMSq6/TbBCGmS7etrNh8pqawEPsdMaTvW4a
Bo1T2NlNQaWsmblVdS8HspwLTDaeQArgrtN92JoCKgZuEbIlFU8ooDDUIaMjstk=
=5ptw
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/4e73ccb9$0$31301$426a...@news.free.fr
Aéris
Hash: SHA1
Le 17/09/2011 00:40, Jean-Yves F. Barbier a écrit :
> ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p3306)
Ce qui n'est pas recommandable effectivement, mais qui ne semble pas le
vecteur de ce piratage.
> ça n'est pas tout à fait vrai: disons plutôt tant que les programmeurs php
> ne contrôleront correctement ni leurs morceaux de code ni les droits des
> fichiers & directories.
Certes, mais PHP ne fait rien pour inciter à du code propre et à de
belles applications.
Le cœur même de PHP est totalement délirant en matière de bonnes pratiques :
— API hétérogènes et mouvantes,
— Intégration d'une foultitude de « librairies » directement dans le core
— Paramétrage hérétique (magic_quote_gpc ><),
— Aucun respect d'une quelconque de normes de codage,
Même le PHP Engine n'est pas thread-safe et plombe Apache (pre-fork au
lieu de worker) ou incite à l'ultra-crade-pas-sécurisé (fast-cgi).
Comment espérer des applis correctes quand l'environnement dans lequel
elles vont tourner est moisi jusqu'à la moëlle ?
> Mais au risque de me répéter, la meilleure parade reste d'inclure le code
> "actif" dans la DB (procs stockées); mais je doute qu'à ce jour ce soit facile
> (voire même possible à 100%) avec mysql.
C'est extrème comme solution, et totalement innapplicable sur une
application digne de ce nom, que cela soit en PHP ou non et MySQL ou non.
Tu imagines le nombre de stored-proc nécessaires ? De toutes les
variantes de paramètres et/ou de sorties différentes ?
Du coût monstrueux de maintenance d'un tel système ?
Et qu'une telle application serait figée dans le marbre à jamais, toute
évolution future étant vouée à l'échec ?
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOc9awAAoJEK8zQvxDY4P9hKUIAJcxOLzRUU1Cz5GkFrKnVarb
W7qAkn5/QV0GvlWQSeLH7upVqsjbJVqr05X4y03+oLTXx6tzi/Rxk2CDsVrfnab7
AiH47O0U3RbFEge/Qm4wODD6rf/eoUrujVMJSUVRMMwmk2f37Sp5ilOkVqCqXi2p
MpXBSmAcMQiMRjTwdEKI+URBEIcfgrVjwQf6iYzhNzXzjfqFiZT83vzIC+v0XKT1
GHo2xpw4JGRAeqWEtxItGYQ6ejCOKqQ4U/28+E9Fqs4b9aGp+Y9UEKhbwic4kPVv
T47b3UJHKvlXy4utpz810zM2oq+O32ElUYE+oSUzsYOV6J6J9tDukD6odj9pdV8=
=9KYH
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/4e73d6b5$0$11287$426a...@news.free.fr
Jean-Yves F. Barbier
> — API hétérogènes et mouvantes,
> — Intégration d'une foultitude de « librairies » directement dans le core
> — Paramétrage hérétique (magic_quote_gpc ><),
> — Aucun respect d'une quelconque de normes de codage,
> Même le PHP Engine n'est pas thread-safe et plombe Apache (pre-fork au
> lieu de worker) ou incite à l'ultra-crade-pas-sécurisé (fast-cgi).
(design vieillot, conso de RAM effarante, etc).
...
> > "actif" dans la DB (procs stockées); mais je doute qu'à ce jour ce soit
> > facile (voire même possible à 100%) avec mysql.
>
> C'est extrème comme solution, et totalement innapplicable sur une
> application digne de ce nom, que cela soit en PHP ou non et MySQL ou non.
> Tu imagines le nombre de stored-proc nécessaires ?
effectuent elles-même leurs propres contrôles sur tables et colonnes (Pg, œuf
corse hein, pas merdesql), d'un côté on perd le temps de contrôle à chaque
appel, de l'autre on gagne une malléabilité énorme et l'abstraction par rapport
aux données; sans compter l'interdiction totale d'accès direct à ces
mêmes données.
La maintenance n'est pas plus lourde que pour un pgm en php, voire plus légère,
parce que si l'on reprend le cas du php (hors code de mise en page), il se
contente d'effectuer des appels à des procs stockées (r/a/u/d); la proc
prenant en charge les autorisations et le traitement réel des données.
> De toutes les
> variantes de paramètres et/ou de sorties différentes ?
les colonnes autorisées (ou renvoie une erreur si pas d'autorisation).
> Du coût monstrueux de maintenance d'un tel système ?
même moins puisque chaque proc a une fonction bien déterminée (quitte à avoir
un peu de redondance dans le code afin d'éviter le morcellement).
> Et qu'une telle application serait figée dans le marbre à jamais, toute
> évolution future étant vouée à l'échec ?
dans des centaines de bouts de code php pour s'y retrouver et modifier ces
morceaux comme voulu, et modifier directement une ou des procs stockées dans
la DB?
À part les langages différents et surtout le fait que le contrôle total
des données soit dévolu à la DB et non-plus à du code externe, je ne vois pas
où se trouve le différentiel de maintenance.
--
Don't everyone thank me at once!
-- Han Solo
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Basile Starynkevitch
Aéris <ae...@imirhil.fr> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le 17/09/2011 00:40, Jean-Yves F. Barbier a écrit :
> > ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p3306)
>
> Ce qui n'est pas recommandable effectivement, mais qui ne semble pas le
> vecteur de ce piratage.
>
> > ça n'est pas tout à fait vrai: disons plutôt tant que les programmeurs php
> > ne contrôleront correctement ni leurs morceaux de code ni les droits des
> > fichiers & directories.
>
> Certes, mais PHP ne fait rien pour inciter à du code propre et à de
> belles applications.
existe depuis un certain temps des tas de langages (ou d'outils de développement
logiciels) pour le Web. Sans être ni spécialiste ni exhaustif je peux citer
http://opalang.org/
http://ocsigen.org/
http://hop.inria.fr/
http://kayalang.org/
mais il en existe d'autres. Les trois premiers (Opa, Ocsigen, Hop) sont développés en
France. Tous sont disponibles comme des logiciels libres.
Et je trouve très dommage qu'ils ne soient pas d'avantage utilisés, notamment pour les
sites de logiciels ou de distributions libres
Cordialement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
Le 17/09/2011 03:20, Jean-Yves F. Barbier a écrit :
> Moins que tu ne penses: je bosse ces temps-ci avec des procs polymorphes qui
> effectuent elles-même leurs propres contrôles sur tables et colonnes
Je serais intéressé par un exemple, là comme ça je ne vois pas…
Comment peut-on gérer par procédure stockée le fait que les arguments
peuvent être variable (tri par date *OU* par nom), avoir des
comportements différents (nombre de post dans un topic, puis liste des
topics, puis liste des posts du topic joint avec la table des auteurs),
ou retourner des valeurs différentes (dans les cas précédents, un
nombre, une liste de topic, une liste de (post + auteur)) ?
Sans exponentiation du nombre de stored-proc et/ou de leur complexité,
j'ai du mal à concevoir…
> de l'autre on gagne une malléabilité énorme et l'abstraction par rapport
> aux données;
Là aussi, je bloque…
À la moindre modif des fonctionnalitées et/ou de la structure de
données, j'imagine assez mal comment on peut éviter un refactoring
monstrueux du nombre tout aussi monstrueux des stored-proc.
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.
> La maintenance n'est pas plus lourde que pour un pgm en php, voire plus légère,
Si on arrive à m'expliquer les points ci-dessus, OK, pourquoi pas…
Pour l'avoir déjà expérimenté sur un projet où la contrainte cliente
était de n'avoir aucune requête dans le code mais tout dans les
stored-procs, ça a été un échec total déjà sur la 1ère version du soft
(de mémoire, on manipulait plus de 500 SP), et un cuisant Armageddon le
jour où on a du refondre les fonctionnalités et les données.
>> > De toutes les
>> > variantes de paramètres et/ou de sorties différentes ?
> Non: il est relativement aisé d'écrire une proc polymorphe qui ne retourne que
> les colonnes autorisées (ou renvoie une erreur si pas d'autorisation).
Cf questions ci-dessus. J'ai du mal à me faire une idée de l'existence
de telles SP.
> Pas plus que des centaines de petits morceaux de code d'un pgm en php, voire
> même moins puisque chaque proc a une fonction bien déterminée (quitte à avoir
> un peu de redondance dans le code afin d'éviter le morcellement).
Et donc à balayer d'un revers de la main toutes les bonnes pratiques de
développement…
> Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre greper
> dans des centaines de bouts de code php pour s'y retrouver et modifier ces
> morceaux comme voulu, et modifier directement une ou des procs stockées dans
> la DB?
En PHP, je ne dis pas, mais même dans ce langage, un programme « bien
conçu » (3-tiers, MVC, template, séparation forme/contenu…) est assez
facilement maintenable et évolutif.
> À part les langages différents et surtout le fait que le contrôle total
> des données soit dévolu à la DB et non-plus à du code externe, je ne vois pas
> où se trouve le différentiel de maintenance.
Il se trouve aussi du côté des outils.
Si je développe en Java, j'ai des outils de refacto automatique, de la
complétion automatique, des navigateurs de code…
Choses déjà passablement existantes en PHP (mais c'est possible) mais
carrément inexistantes au niveau BDD et SP.
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOdHwGAAoJEK8zQvxDY4P9opAIAL9UFNJUGJFNTckN77ijOohT
r4L+l+DlGV0sLL0fxEsciHpdpc/DkFf3NGjvlZ5jxGqjJ2sKKVZB8MqV7qQ5SHyd
HONFra1Lf7oB+8aDffwUJIi9KZTx8TzXgshfWIDNkdMiGhr7a9o+Yd1b/mk02vui
wUJZoHsKylctGl5BRnGV+eguxRtpfkbU4wVGiSOzDct41bZBePn6UAQfa7lWyUWj
fC1gaybies2z7bIE1+kIzdofrVv3LVxAS8ZG4fVMw3JRXvwGcSUNLX58wt5B20hw
wNbn+7dWzP9mkI3fS9l7qwDdKwpxrTzrpXovKcf2v5gc90JJTD6n/Qnqpfd3qSA=
=VNgm
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/4e747c0b$0$973$426a...@news.free.fr
kaliderus
>
> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
Merci.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/CAPrKK3CN-Hym9vVPbUuQULYc...@mail.gmail.com
Jean-Yves F. Barbier
> Comment peut-on gérer par procédure stockée le fait que les arguments
> peuvent être variable (tri par date *OU* par nom), avoir des
> comportements différents (nombre de post dans un topic, puis liste des
> topics, puis liste des posts du topic joint avec la table des auteurs),
> ou retourner des valeurs différentes (dans les cas précédents, un
> nombre, une liste de topic, une liste de (post + auteur)) ?
> Sans exponentiation du nombre de stored-proc et/ou de leur complexité,
> j'ai du mal à concevoir…
maintenant dans la PS, avec juste qq lignes de plus pour gérer ce type
d'indirection.
> > de l'autre on gagne une malléabilité énorme et l'abstraction par rapport
> > aux données;
>
> Là aussi, je bloque…
DB; seules les PS y ont accès, après contrôle des droits de l'appelant.
> À la moindre modif des fonctionnalitées et/ou de la structure de
> données, j'imagine assez mal comment on peut éviter un refactoring
> monstrueux du nombre tout aussi monstrueux des stored-proc.
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.
> > La maintenance n'est pas plus lourde que pour un pgm en php, voire plus
> > légère,
>
> Si on arrive à m'expliquer les points ci-dessus, OK, pourquoi pas…
> Pour l'avoir déjà expérimenté sur un projet où la contrainte cliente
> était de n'avoir aucune requête dans le code mais tout dans les
> stored-procs, ça a été un échec total déjà sur la 1ère version du soft
> (de mémoire, on manipulait plus de 500 SP), et un cuisant Armageddon le
> jour où on a du refondre les fonctionnalités et les données.
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...
> >> > De toutes les
> >> > variantes de paramètres et/ou de sorties différentes ?
> > Non: il est relativement aisé d'écrire une proc polymorphe qui ne retourne
> > que les colonnes autorisées (ou renvoie une erreur si pas d'autorisation).
>
> Cf questions ci-dessus. J'ai du mal à me faire une idée de l'existence
> de telles SP.
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:).
> > Pas plus que des centaines de petits morceaux de code d'un pgm en php,
> > voire même moins puisque chaque proc a une fonction bien déterminée
> > (quitte à avoir un peu de redondance dans le code afin d'éviter le
> > morcellement).
>
> Et donc à balayer d'un revers de la main toutes les bonnes pratiques de
> développement…
différentes PS?
> > Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre
> > greper dans des centaines de bouts de code php pour s'y retrouver et
> > modifier ces morceaux comme voulu, et modifier directement une ou des
> > procs stockées dans la DB?
>
> En PHP, je ne dis pas, mais même dans ce langage, un programme « bien
> conçu » (3-tiers, MVC, template, séparation forme/contenu…) est assez
> facilement maintenable et évolutif.
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.
> > À part les langages différents et surtout le fait que le contrôle total
> > des données soit dévolu à la DB et non-plus à du code externe, je ne vois
> > pas où se trouve le différentiel de maintenance.
>
> Il se trouve aussi du côté des outils.
> Si je développe en Java, j'ai des outils de refacto automatique, de la
> complétion automatique, des navigateurs de code…
> Choses déjà passablement existantes en PHP (mais c'est possible) mais
> carrément inexistantes au niveau BDD et SP.
Par ailleurs je me suis aperçu que la phase de conception est très souvent le
parent pauvre de la programmation; c'est une erreur: quand tu as bien pensé ta
proc il ne te faut que très peu de temps pour la transformer en code
opérationnel.
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.
Rappelle-toi d'ailleurs (enquête sur une douzaine de SSII il y a qq années) que
60% des actions nécessitent un retour chez le client pour non-conformité/bugs/
mauvaise ergonomie/etc (mes propres informateurs me rapportent plutôt un %age
proche de 85%).
Je ne prétend pas avoir la science infuse, très loin de là, mais s'il y a une
chose pour laquelle je suis doué c'est de repérer les erreurs que font les
autres, et par voie de conséquence tâcher de ne pas les répéter.
--
Nadia Comaneci, simple perfection.
-- '76 Olympics
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Jean-Yves F. Barbier
> > Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
> -> Par curiosité, peux-tu développer ce point stp ?
tout comme C il permet le plus agréable des codes comme le plus illisible
et pourri possible.
--
Procrastination means never having to say you're sorry.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Dominique Asselineau
> >
> > Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
> -> Par curiosité, peux-tu développer ce point stp ?
À chacun de vérifier s'il le souhaite.
dom
--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
>> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
> -> Par curiosité, peux-tu développer ce point stp ?
Déjà, à la différence d'autres langages, il est intrinsèquement mauvais,
c'est-à-dire que dès le cœur de PHP, les mauvaises décisions ont été prises.
Au pifomètre, on peut citer des API extrèmement mouvantes
(ajout/suppression de méthodes entre 3 versions consécutives de PHP), un
manque total de convention de programmation (strlen mais str_split), des
fonctionnalités hérétiques (magic_quote_gpc…), l'intégration de
fonctionnalités qui auraient plus sa place dans des libs externes que
dans le core (compression, traitement des cartes de crédit,
authentification Kerberos, tag IDv3…), ou encore le moteur non
thread-safe qui emmerde totalement le monde pour du déploiement.
Tout à été fait pour faire tout, n'importe quoi, n'importe comment et
par n'importe qui.
De l'autre côté, côté développeur, PHP est vendu la plupart du temps
comme le langage à la portée de n'importe qui, y compris du
non-professionnel.
C'est comme pour le domaine de la vente d'ordinateur, on a vendu du rève
en vendant comme quelque chose de simple une chose qui est en réalité
extrèmement complexe.
Étant donné que le core lui-même n'incite pas aux bonnes pratiques, la
plupart des utilisateurs de PHP (je n'ose trop dire développeurs) ont
fait n'importe quoi, ne filtrent pas leurs données avant l'envoi en
base, mélange très fortement PHP et HTML, n'architecture pas leurs
applications…
Et ceci d'autant plus que les paradigmes de PHP comme la programmation
objet sont développés avec les pieds. Je ne sais pas si tu as déjà
tenter de faire de la POO avec PHP, mais on s'y sent rapidement très
frustré tellement on est loin des possibilités de n'importe quel autre
langage orienté objet (héritage buggé, méthodes statiques buggées,
absence de polymorphisme…).
On retrouve au final des applications la plupart du temps totalement
non-sécuritaire (injection SQL, XSS…), bugguées, indémerdables, non
évolutives… Il y a rarement de véritable v2 pour une application en PHP,
tout au plus une v1-bis où on a tout foutu à la benne pour refaire avec
le nouveau cahier des charges.
Après, PHP souffre aussi de gros problèmes par son fonctionnement même.
Il est stateless dans son fonctionnement au sens où chaque appel relance
une réinterprétation intégrale de ton application.
À l'inverse en JEE par exemple, ta conf et ta connexion à ta base de
données est montée une fois pour toute au démarrage de ton serveur
d'application, ce qui permet de mettre facilement et proprement en place
des systèmes de pool, de cache ou de mutualisation des ressources entre
chaque client. Pas besoin par exemple de reloader 30 millions de fois ta
configuration par mois, ça sera le même objet qui transitera pour toutes
tes requètes.
Cela est très handicapant pour PHP, car du coup cela implique de faire «
light » en terme de performance. Impossible par exemple d'utiliser un
ORM type Hibernate, qui prendrait des plombes à se charger à chaque
appel. On pare au plus vite, au plus pressé, quitte à foutre des
requêtes SQL redondées dans tous les fichiers du projet.
Idem au niveau de l'interprétation, c'est au développeur de gérer le
cycle des dépendances, à gros coup d'include dans tous les sens, souvent
en dépit du bon sens, avec des tricks à la con (le tristement célèbre «
require_once('views/'.$_GET['view'].'.php') »)…
Tout ça parce qu'une méthode « propre » serait inabordable pour tout non
professionnel du développement, rendrait le système lent au possible
(stateless quand tu nous tiens…).
Donc voilà, je vais m'arréter là, sinon je pourrais encore y passer ma
journée =)
Si certains sont intéressés sur le sujet (d'accord ou non avec moi =)),
qu'ils n'hésitent pas à me contacter, c'est aussi un sujet qui me
passionne et dont je serais ravi de discuter, en particulier si
quelqu'un a une solution pour éviter de basculer dans le « bordel PHP »
tout en faisant du PHP (qui est quand même une solution qui serait
intéressant (si elle n'avait pas autant d'inconvénients) de par sa
simplicité de déploiement (à l'inverse de Java, Python, RoR ou autre).
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
S1YnU/rSU42Z6o40nh08BNfEZ0OFvUR9Eu+RU16EEaYd3ysC1KjgAb1s1Lw6f/3U
jwdT9tSpo/Odi0hGQJuNCQjUYm4VY1CyPhZsdYa9szskEsDCV/qqJCdqGtZLLGia
YSRgkzdejsBNqNxUtk9lVZvLhCUjpD5Z6d88JqxWaeoydP26GThVvPMqbW9+2i4f
2ZOjlXmPU/eFVMF1mHkM2PPRX81D9ncBXFknz3gGnyto3qAnlQX3I28K+OLAlRB0
fWl4I07j6VC1/USCeW9wIBGily/ft2yqhh2I7+V3EEdMqnQMV7Bb83GfGrH+WkA=
=O4/o
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Basile Starynkevitch
Dominique Asselineau <asse...@telecom-paristech.fr> wrote:
> kaliderus wrote on Sat, Sep 17, 2011 at 02:25:49PM +0200
> > Bonjour,
Basile>>> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
> > -> Par curiosité, peux-tu développer ce point stp ?
>
> Aéris a donné quelques points ce matin dans son message posté à 01:07.
> À chacun de vérifier s'il le souhaite.
déjà plein, et ça prend du temps à rédiger. On en trouve d'une part sur les sites que
j'avais indiqués :
>
> http://opalang.org/
> http://ocsigen.org/
> http://hop.inria.fr/
> http://kayalang.org/
>
> mais il en existe d'autres.
le temps de regarder ces références]
Et d'autre part on trouve des critiques argumentées
de PHP ailleurs, et notamment dans les communautés spécialisées - par exemple
http://lambda-the-ultimate.org et des tas d'autres.
Sans prendre le temps d'expliciter, PHP est mauvais:
* par l'absence de sécurité, dont témoignent toutes les intrusions, par exemple celle à
l'origine de cette discussion.
* par la mauvaise performance (combien de centrales nucléaires économiserait-on en
remplaçant tous les sites PHP par des solutions plus efficaces?)
* par la difficulté de développement (pour des sites conséquents).
Sur ce dernier point, PHP fait la même erreur que Tcl: Si PHP est peut-être un language
potable pour développer une micro-application Web de 50 lignes, il ne l'est pas pour des
applications qui en font plusieurs dizaines de milliers de ligne de code.
En particulier, l'inférence de types qu'on trouve dans tous les languages statiquement
typés récents (Ocaml, Haskell pour les languages généralistes; Kaya et Opa pour les
langages Web) est un moyen pour assurer, par l'analyse statique du code, sa robustesse.
Et le Web est aussi une affaire de continuation (au sens par exemple de
http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/queinnec.pdf et
autres).
De manière générale, je pense fortement que les langages de programmation progressent
(surtout quand on y inclut ceux produits par la recherche plus ou moins académique).
L'argument majeur, et très conservateur, en faveur de PHP, c'est que n'importe qui peut
prétendre le connaître. Et donc qu'un employeur peut trouver quelqu'un, payé presque au
SMIC, pour pisser du PHP. La réalité, c'est que le développement de logiciels (y compris
Web) est compliqué quand il s'agit de développement d'une certaine taille; que c'est donc
un métier qui demande des qualifications, et qu'un ingénieur Bac+5 correctement formé peut
rapidement apprendre des langages (qu'il n'aurait pas appris à l'école ou à
l'université). Conséquemment, une entreprise aurait probablement intérêt à investir dans
du personnel qualifié.
Désolé, mais j'ai la flemme de rédiger une réponse plus complète (alors qu'il en existe
déjà pleins ailleurs).
Cordialement.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
Le 17/09/2011 14:50, Jean-Yves F. Barbier a écrit :
>> 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.
OK, je m'attendais à cette réponse =)
> 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.
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'impression qu'on
s'éloigne très fortement de l'objectif des PS.
>> 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.
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 PS,
arriver à faire ce genre de trucs (pseudo-code, et non sécuritaire 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écurité à 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…).
> 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.
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
>> 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.
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, « grep » 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 production.
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é de 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 farfelus.
À l'instant T0 de la signature du contrat, ils n'étaient pas farfelus.
À l'instant T0+18mois et 500 SP plus tard, ça l'est devenu un peu plus…
> 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...
Cas classique, mais à la réponse à un appel d'offre et avant 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épondre à un appel d'offre de 1.000 pages).
> 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:).
J'imagine bien =)
> 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 final.
« 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 duplication, 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 « identiques mais
pas tout à fait », fortes chances d'arriver à factoriser tout ç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 ce 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 du 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 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.
Ça se prête généralement pas trop mal à tout type 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 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.
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 à prendre en
compte =)
> 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.
Là, le pissage de code au kilomètre, c'est clairement pas ma philosophie
non plus.
Je préfère 3 lignes qui fonctionnent, testées et validées, faites en 1
semaine, que 300 lignes hérétiques (que je me ferais une joie de
reverter !) en 2h !
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOdKaiAAoJEK8zQvxDY4P9+mIH/2we5Pw+VyWBUE/dBH1Rfgce
78XJOZpWkSBH7Xlzqu+IYlyIq+Z/zRQ09jdm8mscPAhLlS4NINWBoeWoWNAHWZI2
n8axYjHAFvaGCbIkwt9h5GQpJdOjsaw3azjjBPQEfZdcDiWdNhYmAE3Tu8l/9z9Z
m4SXZ5OjOrPLE5oYOZBTU9oQUPxUUI0k195DrBlDCGboQ+3kk6qZOs1A7GrPienJ
y7x4fb/+81KrVn+vUIp5/NAajkl85PmXG/U+3xDgSyL1wc4/AXCyzs6WDXYKf2NT
rAprOSbDrOedvPyDpZSNY48aPsjxGy4LAk57up7jT+5alwVmwzx/r4vbNtxaytc=
=WY10
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/4e74a6a7$0$7286$426a...@news.free.fr
fabrice régnier
A mon avis et tout simplement:
Puisque tu utilises Apache, tu peux mettre en place une identification
ident/mdp avec .htaccess (htpasswd) au dessus de toutes tes applis web
(phpmyadmin, myphpscripts_bien_pourris, ...)
Tu dois autoriser le port 3306 que pour le localhost (si c'est possible).
Et puis (rien à voir avec ton problème actuel [mais surement futur ;) ]
) j'ai aussi vu que le port 22 était ouvert. Si c'est pour le sshd,
remplace le par le port 2201, ça va déjà calmer les robots.
Bon courage!
a+
f.
Le 15/09/2011 22:50, Frédéric ZULIAN a écrit :
>
Jean-Yves F. Barbier
...
> 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'impression qu'on
> s'éloigne très fortement de l'objectif des PS.
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.
...
> Oui, ça d'accord, mais les PS sont quand même ultra-limitées…
Archi faux: il faut bien comprendre qu'une PS, c'est du code (et pas n'importe
lequel: primairement orienté DB).
> Elles ne supportent pas les arguments optionnels par exemple.
Encore archi faux: avec une PS on peut faire tout ce que l'on veut. Reste à
apprendre comment le faire ce qui n'est pas une mince affaire parce que
réflexion PGM ≠ réflexion DB.
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).
> Comme je te l'ai mentionné, je ne vois pas comment on peut, via du PS,
> arriver à faire ce genre de trucs (pseudo-code, et non sécuritaire 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…
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.
> 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écurité à 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…).
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.
Et pour terminer, absolument rien n'empêche d'avoir une PS qui renvoie un set
de records qui elle-même appelle une autre PS pour effectuer un autre
traitement.
Encore une fois: OÙ est la différence avec du code php morcellé??
...
> 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
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.
Encore une fois, c'est là que l'on voit les différences (profondes) entre
réflexion de programmation et réflexion DB.
...
> 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.
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??
> Surtout que supprimer un champ dans une SP, ça va encore, « grep » le
> verra. Mais difficile de grepper un champ qui n'existe pas encore parce
> qu'on veut l'ajouter.
Comme dit plus haut, il suffit qu'il soit donné en parm à la PS.
> 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 ?
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.
> > 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 production.
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.
> 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é de ne pas
> avoir mis de « SELECT * »…)
V. plus haut.
Et dans une PS, il est excessivement facile de renvoyer un champ calculé (pour
peu, bien sûr, qu'on ait les bonnes colonnes déjà existantes).
> > - ET avant tout se rappeler qu'un pro a le DEVOIR
> > (juridique!) de dire non à son client si ses desiderati sont farfelus.
>
> À l'instant T0 de la signature du contrat, ils n'étaient pas farfelus.
> À l'instant T0+18mois et 500 SP plus tard, ça l'est devenu un peu plus…
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).
Pour ce qui est de la clarté, un client c'est comme un clébard: ça s'éduque;
une façon simple de faire est de lui expliquer que ce que LUI considère comme
une modif triviale peut prendre une semaine de boulot, alors que ce qu'il
considère comme extrêmement compliqué peut dès fois être réalisé en moins
d'une heure.
Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
conception de la DB.
> > 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...
>
> Cas classique, mais à la réponse à un appel d'offre et avant 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,
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é.
> et que toi tu es pressé par les délais (4 jours pour répondre à un appel
> d'offre de 1.000 pages).
Et pourquoi pas 24H tant qu'on y est!?
Si vous répondez à n'importe quoi en 6 secondes 22 il ne faut pas venir se
lamenter après que le client n'a pas dit çi ou ça.
...
> > 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 final.
> « 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 duplication, centraliser
> l'information, factoriser mon code…
O_o tu fais de la POO en php...
> 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 « identiques mais
> pas tout à fait », fortes chances d'arriver à factoriser tout ça au
> niveau code quand les SP feront un gros copié/collé de derrière les fagots.
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).
> > Dans mon système, le MVC n'existe pas (en fait c'est la PS qui a ce 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 du MVC
> (qui est ma DAO en JEE par exemple), il te manque encore toute la partie
> C et V
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.
> > 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.
>
> Ça se prête généralement pas trop mal à tout type 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.
Moi aussi j'aime bien les Lego, mais c'est pas avec ça que je construirais ma
baraque...
Plus sérieusement, ces outils ont été développés pour des raisons et des
besoins particuliers, PAS pour être mis à toutes les sauces.
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.
> > 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.
>
> 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 à prendre en
> compte =)
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é).
--
Is this really happening?
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20110917174...@anubis.defcon1
Aéris
Hash: SHA1
> Tu dois autoriser le port 3306 que pour le localhost (si c'est possible).
devrait écouter que sur lo !
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
JNm+XrMHeM8S79fOp2eUkbjZtgvoVlutq2wA3o1KooJEo8DfXtvP9HAks9PYwvFx
xnpMbwuBnnVKDzS2nUjenpryZm847d5LDTUfiWl9gZEFM3W3NsG4V/4AbiZIpbTt
qfJjPmIgF2pcl2u13rnv9cawci8bJuM8t4TJiqiVnTwuRwoBLxMBN96k4xmVoeJi
KAT3r+D5Noay+fHtU8W87ryhEQVQ6yuSnfg45idrbcScXp30OZkqevlugX70WSrL
MJljEveAp/GFc6lykCEBZMTwk7rf5GHIugo2aM61hw7NspsILjPbUwgx00SqNys=
=zh4F
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
> 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).
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 travail 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 !
> Ca permet aussi de remplacer certaines VIEWs trop complexes à manier/modifier,
> notamment en maintenance.
j'en ai, avec le traitement de procédures trop longues ou inefficaces
côté applicatif.
> 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.
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é totalement vain.
> 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).
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.
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é...
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.
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 !
> 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 '*',
nommés.
> 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??
Ça t'apporte pas mal d'autres choses, comme les pools de connexion, les
caches multi-niveaux, l'indépendance du moteur…
Par exemple avec Hibernate, je vais utiliser à plein les principes de
localité temporelle et spatiale et économiser un maximum de requêtes
superflues grâce aux caches.
> 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.
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…
> 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.
J'ai même dans mon entreprise des demandes d'évolution sur du soft de 30
ans d'âge !
> 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).
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 fonctionnalité
avait déjà été SPifié ou si le travail restait à faire, pour trouver
telle SP qui devait être corrigée, ainsi que toutes ses variations
potentielles.
> Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
> conception de la DB.
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 effroyables (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'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.
>
> 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).
uniquement le M qui différera (JPA dans mon cas, SP dans le tient).
Et donc la V n'a *RIEN À FAIRE* dans le moteur.
Pire, c'est même contraire à la philosophie MVC qui stipule qu'on doit
pouvoir changer de vue voire en avoir plusieurs pour un même M.
Si demain je veux mettre des web-services ou faire une appli lourde au
lieu de mon appli web, je n'ai théoriquement que le V à changer et un
peu le C, le M reste *STRICTEMENT* le même.
> Pour la partie C, elle est aussi incluse dans la PS.
Ç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 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.
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 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).
On sait d'avance que les évolutions seront nombreuses (surtout dans mon
domaine principal, l'industrie), et les équipes très fluctuantes (SSII).
Le soft se doit d'être abordable tout en étant suffisamment bien 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 certaines, même hors normes
> SQL, facilitent grandement la vie.
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 lieu
de l'auto-incrément MySQL.
> 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.
Comme remplaçant, PostgreSQL !
> 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é).
Mais même tout ça bien calibré, les millisecondes de latence du
navigateur seront pinuts comparées à la bonne grosse seconde de calcul…
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
fCETFxK2xY0HXnI3BJ54/0iXpRhC4dMvrZAME6dJjpqT6ssercedH8YIrDUO5sEp
poy0FvAf/+WnGf4qymLbQYWaePW/0EcEYvL3mJQhgURnqnwXaEguSkKkVOZk7yuQ
h+2wTNIwXEWqNR4qG1o7rYUJZJS4Rnz+iRZG+KG02Zj+L1Ym3Tivg8cVOQRFIw+P
re5Jtq0LONBlyLmWsiAizcMP30hq6xCPx4ohft/ldaHx6hJYE8oY9boo4S4TbFip
I6ebU19hwGpdN6+oXBjMJGq84nprKGV6S8KocdhSzK/JHbV4lsgSTyj9x60D/Aw=
=Cf4T
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Nicolas KOWALSKI
> 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.
Je plussoie cette remarque.
J'ai eu l'occasion de faire du Perl pour de la supervision (mon) et de
l'analyse de logs (issus de mon); on peut faire des choses propres,
ultra-rapides, avec des sorties en HTML nickel (passées au validator w3c
les doigts dans le nez). Pour les sorties achtéaimelle, j'ai en
particulier beaucoup apprécié le module CGI, pour lequel je n'ai pas
trouvé d'équivalent PHP ; on code en Perl, pas en HTML, et le module
fait le nécessaire pour retranscrire le tout proprement.
--
Nicolas
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20110917181...@petole.demisel.net
Jean-Yves F. Barbier
...
> OK, mais on sort totalement du cadre des procédures stockées lambda…
Tout dépend de la conception de lambda; dans le cas présent, il s'agit de
répartir les tâches équitablement entre codes int/ext.
> 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 travail et de
> personnes, je n'en vois pas l'intérêt.
Chacun chez soi...
Autrement dit pourquoi chercher à gérer la sécu des accès au niveau applicatif
alors que c'est déjà intégré dans la DB!?
> 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.
Par rapport à Oracle, il manque encore qq autres contrôles, mais à la vitesse
(ET surtout la qualité) à laquelle les devs Pg vont, je ne doute pas que d'ici
la fin de l'année prochaine on y soit.
> Et qui dit 2 sources de code dit 2× plus de risque d'erreur !
Nan: ça revient au même, la différence c'est que le code ext n'exécute plus
qu'un simple appel à la SP.
...
> > 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.
>
> Gros problème que j'y vois : cette manière de penser (que j'imagine 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é totalement vain.
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.
> > 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).
>
> 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…
Ben ceux que je connais sont en Gal aussi des devs, justement parce que c'est
une discipline très différente de la programmation proprement dite.
> > 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…
Même si N=300 ça ne pose pas de PB insoluble (surtout que dans Pg, une fois
passé le premier appel qui déclenche la compilation, c'est le pseudo-code qui
est exécuté).
> > 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é.
Eventuellement pour la traçabilité, mais normalement si la DB est bien concue
ça se traite par une table 1-1-self (et par voie de conséquence, par des appels
récursifs à la SP).
Pour le reporting c'est une toute autre histoire, notamment dans les grosses
entreprises, parce que toutes les enquêtes montrent que chaque nouveau chef
vient ajouter son grain de… sable dans la machine pour prouver qu'il existe,
mais qu'au final moins de 10% des traitements de données (en Gal les
indicateurs std) servent réellement à qq chose dans les processus de
décision/optimisation.
> > 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ù 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.
> > 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 '*',
>
> C'est pour ça que je n'utilise pas le positionnel, mais bien les champs
> nommés.
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
> > 2- Rien n'empêche d'avoir lesdites colonnes en paramètres de la PS,
>
> Ce qui ouvre la voie à de l'injection SQL ? =)
Pas du tout, il existe des mécanismes simples dans Pg pour se prévaloir de
toute possibilité d'injection par les parms d'une SP.
...
> > 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??
>
> 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…
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.
...
> > 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.
>
> 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…
D'où l'intérêt d'upgrader par package complet - sinon il suffit d'ajouter une
SP qui renvoie la version (mais ça reste une Tmauvaise solution).
...
> Un client a souvent du mal à définir son futur, surtout à 18 ou 30 mois.
J'entends bien, mais dans ce cas il faut être aussi clair dans l'autre sens:
soit il aura un soft très spécialisé et totalement adapté à son cas présent
(mais qui demandera plus de travail lors d'une évolution), soit tu lui fais
un truc extrêmement malléable avec ORM, N-tiers et tout le toutim, au
détriment complet des perfs (mais qui se modifiera très facilement).
A ma connaissance dans ce domaine, il est totalement impossible d'avoir le
beurre, l'argent du beurre et le cul de la fermière (cochonne qui a des gros…,
ha non, merde, c'est l'infirmière:)
> J'ai même dans mon entreprise des demandes d'évolution sur du soft de 30
> ans d'âge !
Je pense que ça mérite une analyse poussée au cas par cas; j'ai pu jeter de
temps en temps un œil a certains vieux softs qui étaient terriblement bien
faits, alors que d'autres étaient une vraie cata.
> > 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).
>
> 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…
Apparemment mauvaise analyse dûe à une connaissance pas assez approfondie de
la DB utilisée.
> Les développeurs s'arrachaient la tête pour savoir si une fonctionnalité
> avait déjà été SPifié ou si le travail restait à faire, pour trouver
> telle SP qui devait être corrigée, ainsi que toutes ses variations
> potentielles.
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
> > Mais dans le cas présent, je soupçonne fortement (et à priori) un défaut de
> > conception de la DB.
>
> C'était le cas en partie, mais la base avait été héritée d'un ancien
> système et on ne pouvait pas trop y toucher.
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.
Parce que si tu réponds oui à une telle demande, la première merde te reviendra
dans le museau comme un boomerang (les clients ont l'amnésie absolue quand il
s'agit de responsabilité).
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.
> 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…).
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 fenêtres de 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.
> > 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é.
>
> Les clauses sont là, mais rarement appliquées.
C'est une erreur classique et désuette; par exemple, les tribunaux du fisc ont
établi que si tu fais allusion à une clause de délai de paiement dépassé sous
astreinte d'intérêts de retards ET qu'il y a retard ET que tu ne fais pas
jouer la clause, tu es redressable sur le CA non-généré (merveille de ce pays
de cons, dirigé par des incapables tout-puissants pour qui les entreprises
sont l'ennemi à abattre).
...
> > 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).
>
> Et de redescendre l'injection SQL un poil plus bas…
Non, comme dit plus haut, il est facile d'éviter toute injection dans une SP
postgresql.
...
> > 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
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.
> > 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.
>
> 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…
Tu mets le doigt sur l'un des PBs majeurs actuels: on demande aux gus sortant
d'une école d'être immédiatement opérationnels, ce qui est une ineptie totale.
D'abord parce qu'il y a une culture d'entreprise à acquérir, et que ça ne se
fait pas en un jour (eg: certains chefs demande un reporting hebdomadaire,
d'autres journalier, et ceux qui ont compris font confiance à priori); et
ensuite parce que même avec des tas de stages ils ne sont pas obligatoirement
tombés sur les même cas.
ET, très contradictoirement, les entreprises ne veulent pas assumer cette
accoutumance à leurs us et coutumes.
Sans compter qu'une entreprise est comme un individu: elle ne peut pas tout
faire, surtout au jour d'aujourd'hui où l'on demande à chacun d'être un
spécialiste.
Alors la façon simple(iste) de se défausser, c'est de tout faire, un peu
n'importe comment, tout en générant un turnover important dans le personnel
qui n'en peut rapidement plus, ce qui va au détriment des propres intérêts de
l'entreprise.
Là-dessus je pense qu'un coup d'œil sur les manières de faire de nos voisins
Teutons en particulier (et Alémaniques en Gal) permettrait d'y voir bcp plus
clair.
> > 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).
>
> Oui, à long terme.
> On sait d'avance que les évolutions seront nombreuses (surtout dans mon
> domaine principal, l'industrie), et les équipes très fluctuantes (SSII).
> Le soft se doit d'être abordable tout en étant suffisamment bien gaulé.
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.
> > 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.
>
> 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 lieu
> de l'auto-incrément MySQL.
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.
> > 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.
>
> C'est bien pour ça que je l'ai fait bannir de notre bureau d'études.
> Comme remplaçant, PostgreSQL !
Voila une chose qu'elle est bien!
Comme d'hab, il n'existe pas une solution mais une multitude de solutions
possibles pour un même PB - et je veux bien concevoir que dans le cas que tu
décris, ORM et autres aides forment une béquille qui a ses avantages et ses
inconvénients en fonction de l'angle d'observation.
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.
--
The chicken that clucks the loudest is the one most likely to show up
at the steam fitters' picnic.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20110917224...@anubis.defcon1
Aéris
Hash: SHA1
>> 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.
Cf un peu plus loin.
> 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,
– Mes tests U tournent sur une db H2, ce qui permet de lancer les tests
sans trop se soucier de l'environnement et donc de rester « unitaire »
et non « intégration »
— Ma prod tourne sur une db PostgreSQL
Le tout en ne changeant qu'un seul fichier de conf (et plus exactement 2
lignes de XML, le driver et l'URL de connexion), et rien au niveau du code.
> * qu'il existe un moteur capable de rendre les même services.
Ça ne sera pas forcément exactement les mêmes services, mais le même
résultat, Hibernate se chargeant de convertir mon besoin en appel natif
à la base, fonction du moteur qu'il y a derrière.
> * que ladite portabilité ne se fasse pas au détriment des perfs.
Même mieux, Hibernate soulage énormément la bd, en cachant les requêtes.
1 SELECT + N UPDATE + 1 DELETE génèrera uniquement 2 requètes en base,
le SELECT et le DELETE, les UPDATE étant inutiles…
Idem avec les phénomènes de cache, N SELECT conduiront à 1 seul SELECT
réel, les autres tapant directement dans le cache.
J'ai même déjà vu des systèmes avec une RAM suffisamment dimensionnée
parvenir à plus ou moins 0 requête SQL (une de temps en temps en cas de
défaut de cache).
> Même si N=300 ça ne pose pas de PB insoluble (surtout que dans Pg,
> une
fois
> passé le premier appel qui déclenche la compilation, c'est le
> pseudo-code qui est exécuté).
toléré en développement normal est 10), c'est de l'hérésie et ça pue à
plein nez le truc inmaintenable…
>> 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.
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…).
> 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
Je peux faire un « SELECT * » mais accéder aux données 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 perturbent
pas mon code), sans avoir de problème d'ordre.
Avec Hibernate, c'est encore plus simple, parce qu'il génère tout seul
la liste des colonnes qui l'intéresse !
En gérant celle en lazy-loading, etc…
> 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.
Et qui n'ont pas été développés exclusivement pour lui.
Citons par exemple :
— Caches : EHCache, JBoss Cache, Oracle Coherence…
— Pools : C3P0
> Apparemment mauvaise analyse dûe à une connaissance pas assez
> approfondie de la DB utilisée.
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 bcp
> d'avantages: release when ready AND tested, puis ajouts de
> fonctionnalités par releases, jusqu'à release 1.0
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émenter «
chercher les X qui contiennent Y et les trier par Z », t'as 2 solutions :
— 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 directement 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.
clefs étrangères, étaient mal indexées ou conçues.
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 compliqué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 complexité
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 fourni
le service externe réel, qui nous balançait des fichiers de 200Mo et
quelques 80.000 règles de répartition !
> 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.
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 données
> externes alors qu'elles auraient dû se trouver dans la DB?
sous la forme de web-services.
> Pour te donner une idée, même les tailles & positionnements des
fenêtres de
> mon projet sont stockés dans la DB.
Les données de conf sont « dynamiques » et rentrent très mal dans une
base relationnelle.
Par exemple, des règles peuvent générer entre 1 et N répartitions,
fonction de données variables de la transaction bancaire de départ (lieu
d'émission, détenteur carte, type de carte, débiteur, créditeur,
fournisseur de la carte…).
> 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.
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ètres, 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 pouvant ê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 « sous-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, mais
uniquement transaction par transaction.
>> 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.
Ajouter un écran n'est qu'une histoire de présentation, pas de processing.
Si je veux présenter mes données en XML d'un côté et en HTML de l'autre,
mes requêtes sont strictement identiques !
> 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.
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.
> 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.
gueule « nouveau projet !!!! » =)
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
dE4wgkcB+S6IEAt/5fQuhfFkZqYd2X6lgiud8XwiBEO6TtCEWGcgbx6aIW9f0Uiq
o+2LDhpSOPIhTDv67/7GQlIGOhQTk3gQViKOliw93abdlF6xs7+TFTcLK81z98eX
EjcBUEixiUJX3smzSC598BLIyet9ES+7C/EE9zZSMdqIOCZQUqibSUPPG35brwhH
Av/z7TCFcaexFCoZeoNUj7pJ2evUmxHQ1k1uklgvKFMg1vjfAWe9QMXcoOP8p9NH
4Bg8Bgws9ZyXJpeB6HirDDDQeZNhMOL5CShYXI8jX4p7ZZw14Fe5ROXWHsa9tNE=
=0l2Z
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Jean-Yves F. Barbier
> > 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 maximum
> toléré en développement normal est 10), c'est de l'hérésie et ça pue à
> plein nez le truc inmaintenable…
...
> 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…).
polymorphiques à encryptions multiples targetant aussi bien ces DBs que leurs
backups...
...
> 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 perturbent
> pas mon code), sans avoir de problème d'ordre.
>
> Avec Hibernate, c'est encore plus simple, parce qu'il génère tout seul
> la liste des colonnes qui l'intéresse !
> En gérant celle en lazy-loading, etc…
...
> > approfondie de la DB utilisée.
>
> Non, juste que la base avait des tables à plus de 400 colonnes, et des
> critères de filtres sur 100 ou 150 critères.
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).
> > 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
>
> Le soucis n'était pas d'ajouter de nouvelles fonctionnalités, mais 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émenter «
> chercher les X qui contiennent Y et les trier par Z », t'as 2 solutions :
> — 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 directement 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 les
> clefs étrangères, étaient mal indexées ou conçues.
> On avait même réussi à poser une clause de non-engagement sur les perfs.
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).
> 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 compliqué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 complexité
> 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 fourni
> le service externe réel, qui nous balançait des fichiers de 200Mo et
> quelques 80.000 règles de répartition !
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...
...
> 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…
rédhibitoires.
> > 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?
>
> Les données provenaient de systèmes externes et/ou de sous-systèmes,
> sous la forme de web-services.
histoire :(
...
> 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ètres, 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 pouvant ê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 « sous-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, mais
> uniquement transaction par transaction.
...
> > 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.
>
> 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.
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 ;-)
--
The attacker must vanquish; the defender need only survive.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
> 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).
Mais sinon, même sans ça, j'ai du mal à voir comment on aurait pu faire
mieux, une transaction bancaire étant RÉELLEMENT aussi complexe à
décrire, le modèle de données l'est tout autant.
Ou alors il aurait fallu des champs banalisés ou structurés, mais on
aurait perdu en capacité de requétage.
> Effectivement, ça n'est gérable que par du middleware.
à ce niveau de complexité.
Après, il y a peut-être des manières de faire que je ne vois pas pour le
moment qui permettent de limiter les dégâts, mais de ce que je connais
des SP et de leur fonctionnement, j'en doute très fortement.
> 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).
SQL Server, SSIS…).
L'absence d'indexes s'expliquait par exemple par le fait que les tables
étaient partitionnées par date pour des contraintes de purge rapide des
données (daily rolling window). Sauf que du coup, la pose d'indexes ne
contenant pas la clef de partitionnement était interdite afin de pouvoir
aussi partitionner les indexes, sinon le rolling conduisait à une
reconstruction intégrale des indexes, qui plombait les purges (3j au
lieu de 10s).
> 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...
En tout cas en SSII, les appels d'offre qu'on reçoit, c'est le cas,
sinon la boîte en face l'aurait gardé en interne !
La plupart du temps, le client est elle-même prestataire et se rend
compte qu'il ne pourra pas tenir les délais de l'appel d'offre initial,
mais il doit bosser. El prend le contrat, et sous-traite au forfait une
partie plus ou moins cruciale, en tentant de cacher la misère.
Celui qui signe la sous-traitance s'engage avec obligation de résultat,
ne tiendra pas ses délais, mais la boîte d'origine pourra rejetter la
faute du retard (anticipé…) sur son presta, voire lui faire payer des
pénalités qui compenseront celles (prévues…) que la boîte doit payer à
son client final.
> J'entends bien, mais là encore les défauts de base de la DB étaient
> rédhibitoires.
Une fois qu'on a (enfin) pu faire comprendre au client que les SPs,
c'était pas le bon plan, on a foutu un middleware et un ORM, et roule.
En 3 semaines, le taff était fait, contre 12 mois pour la version SP (et
sans parvenir au bout…).
>> 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 :(
que de ton seul sous-système.
La plupart du temps, tu t'interfaces avec des systèmes tiers, via
web-service, échange de fichiers, FTP, SSH, messaging…
La base de données est souvent totalement contre-indiqué pour ce genre
d'usage (N clients différents, polling de masse, données peu ou pas
structurées, contrôle d'intégrité et de cohérence, chiffrement, signature…)
>> 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.
Si on avait pas eu le soucis d'historique du bordel, c'est clair que
c'était OLAP, ETL, Birt, OW2…
> 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?
Faut bien bosser un jour et le client cache très bien la misère.
Les 80k de règles étaient décrites dans le CdC comme ceci : « le système
doit s'interfacer un sous-système externe. En annexe, le XSD des
fichiers d'entrée ainsi qu'un fichier *d'exemple* ». L'exemple donné
était quand même assez conséquent (2 ou 3ko), XSD/XML on sait facilement
faire, on a pas forcément pensé qu'on allait se prendre ×20 au réel,
d'autant plus qu'on était plus paniqué par l'état de la BdD et de
l'obligation de SP.
Mais certes, on aurait du réagir sur le mot « exemple », et demander des
précisions sur la volumétrie.
> Et pourquoi à la base les concepteurs DB n'ont pas mis un véto absolu, au vu de
> l'état de la base à reprendre?
s'engageait sur aucune perf étant donné qu'on était contraint sur le
modèle de données.
> 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 ;-)
Dans la pratique, je sais par expérience que malgré une erreur déjà
commise, ça n'empèche pas les SSII de re-signer la même connerie plus
tard, parfois avec un peu plus de garde-fous mais resigner quand même.
L'exemple le plus récurrent étant le fait de signer un appel d'offre en
considérant le CdC client comme spécification, au motif que le CdC
paraît bien détaillé (plus de 300 pages, 1.000 besoins numérotés pris
comme « exigences », diagramme de séquence, copies d'écrans ou
mock-up…). Et qu'on se fait déboîter derrière quand on se rend compte
qu'il va falloir 2 mois de specs pour 5 jours vendus (incohérences
métiers et/ou techniques, trous dans les besoins, manques de précisions,
méprises sur des termes communs qui sont en réalité métiers)…
Le pire cas que j'ai vu passer, c'est une incompréhension sur un terme
du langage courant, qui changeait tout le fonctionnement du système si
on prenait sa signification réelle métier.
En gros, c'était comme si je te disais « tu n'as pas éteint la lumière
». En langage courant, tu en comprends qu'elle est allumée et que tu
dois aller l'éteindre. En langage métier, ça signifiait qu'elle était
peut-être allumée et qu'il fallait l'éteindre, mais aussi que si elle
était éteinte, il fallait l'allumer puis l'éteindre aussitôt !
Faute de specs dignes de ce nom, déboîtage du projet…
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
vM+CGeEtAD1wFDuzPMODJdej6TiMTRHEesZY2PSXBn+vdlPqwXfb0y/HqOd7PfCC
pQcpqR+DNqh/xCsBkVO7Oa8aDUhxfap1rTwrFcTKvBUulKNaaKwY3Vt8T/1sYQkt
kEEZBP847AURx6++7InvO0D6u4JkdkrIX7bnc9aAG6U7LBVtMTpP/49+hzRMXStm
sl/IvkNXQ/lIouIZou+2KnR0eVf9eGAER44Sd+FyfidneotzB54G9PFuoNwdMZ3h
ie9g/UiXgJeW33DEpQaNQgdLdI1z4VJWAjBehR56OnwuL7I72P8iCHAQs7qihOg=
=L5Rl
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Jean-Yves F. Barbier
...
> > avez-vous pu accepter de reprendre cette DB telle quelle?!;
>
> Faut bien travailler parfois =)
...
> compte qu'il ne pourra pas tenir les délais de l'appel d'offre initial,
> mais il doit bosser. El prend le contrat, et sous-traite au forfait une
> partie plus ou moins cruciale, en tentant de cacher la misère.
> Celui qui signe la sous-traitance s'engage avec obligation de résultat,
> ne tiendra pas ses délais, mais la boîte d'origine pourra rejetter la
> faute du retard (anticipé…) sur son presta, voire lui faire payer des
> pénalités qui compenseront celles (prévues…) que la boîte doit payer à
> son client final.
ne se vende pas" (mais je comprends que le taff ne courant pas les rues...)
...
> > histoire :(
>
> C'est souvent le cas en système d'info, tu ne dépends que très rarement
> que de ton seul sous-système.
> La plupart du temps, tu t'interfaces avec des systèmes tiers, via
> web-service, échange de fichiers, FTP, SSH, messaging…
> La base de données est souvent totalement contre-indiqué pour ce genre
> d'usage (N clients différents, polling de masse, données peu ou pas
> structurées, contrôle d'intégrité et de cohérence, chiffrement, signature…)
...
> du langage courant, qui changeait tout le fonctionnement du système si
> on prenait sa signification réelle métier.
> En gros, c'était comme si je te disais « tu n'as pas éteint la lumière
> ». En langage courant, tu en comprends qu'elle est allumée et que tu
> dois aller l'éteindre. En langage métier, ça signifiait qu'elle était
> peut-être allumée et qu'il fallait l'éteindre, mais aussi que si elle
> était éteinte, il fallait l'allumer puis l'éteindre aussitôt !
> Faute de specs dignes de ce nom, déboîtage du projet…
avec le client dans le rôle de Ténardier; et puis tu pourrais intituler
les commentaires "la p'tite causette" ;-)
Je pensais naïvement qu'avec le temps les déboires des SSII s'étaient un peu
atténués, mais je m'aperçois que c'est exactement le contraire.
--
Please read the prospectus carefully before you invest or send money.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
Le 18/09/2011 14:20, Jean-Yves F. Barbier a écrit :
>> Faut bien travailler parfois =)
>
> À n'importe quel prix (heu... perte)?
Certains soutiennent qu'il vaut mieux 10 ingés sur un truc qui ne
rapporte rien au final (coût salarial = X, facturation client = X) que
10 ingés en intercontrat (coût salarial = X, facturation client = 0) =)
> Tu devrais faire un blog avec tous tes déboires: on dirait du Victor Hugo,
> avec le client dans le rôle de Ténardier; et puis tu pourrais intituler
> les commentaires "la p'tite causette" ;-)
Ouaip, il risquerait d'être assez rapidement rempli je pense ^_^
> Je pensais naïvement qu'avec le temps les déboires des SSII s'étaient un peu
> atténués, mais je m'aperçois que c'est exactement le contraire.
Ben tant qu'on restera dans le fonctionnement actuel des appels d'offre,
c'est-à-dire un choix de prestataire fonction du montant du devis à 90%
de la décision, on aura forcément ce genre de problème.
Quand on signe enfin un contrat, le 1er réflexe au niveau technique,
c'est presque « Merde, on était moins cher que tout le monde, qu'est-ce
qu'on a raté ‽‽‽ » et d'aller au charbon pour tenter de connaître les
tarifs des devis de la concurrence et des infos pour savoir où on va se
faire niquer et qu'eux avaient vu.
À titre de comparaison avec l'Allemagne (où les achats refuseront
purement et simplement une proposition en dessous de l'estimation
interne et où la MOA est prêt à mettre plus de moyen à condition de
garanties fortes de tenir les délais) qui doit obtenir des taux de
dépassement de projet de l'ordre de 20%, en France on serait plutôt à 80%…
Le mode « forfait » est souvent vu par les clients comme un bon moyen de
se faire financer le projet par le prestataire, parfois avec des
méthodes douteuses, comme par exemple de faire miroiter de la régie ou
de la TMA à long terme si on mène le projet forfaitisé à son terme (quoi
qu'il en coûte au presta, et quelque soit le retard).
À ce sujet, je serais d'ailleurs intéressé par des retours d'autres
collègues de SSII (voire de clients, mais là j'ai des doutes d'en avoir
un jour !), parce que malgré que la situation me semble générale, il y a
une espèce d'Omertà là-dessus, et qu'au contraire tout le monde y fonce
tête baissée, par peur de la perte du client.
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOdefTAAoJEK8zQvxDY4P9AQgIAJS4GFX1gNJU7CQnTx/tWgp1
62NJZZQu8bQ80HL8wHZRe9xN16wREAluOmb+AsWwRBwZvUK4RCHnfCBDABx1UYBQ
a4A0jrADV/6849V82iEInc5NeUj1/pdZmiojN22tpi/qMl4MtC8N2h5vs5SDTIV1
NOUtDNStSgmQWRiwnxOYekazQo4elkcBAPgfnFPEG5QnysIstsTzhyS4z4OrhCb2
i/l8rIbszxru6B4Slvp4C2Ufg9oYDmERjpKhg0nxdy5UZAjyDIbyuUJnIJfIda96
kCGsVbT1KdSvkM7tJrvD/GF1r4oB1x7BIenSuH7S/QcSoVqiKnQvC97UCpi3q74=
=Dg2C
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/4e75e7d9$0$15032$426a...@news.free.fr
Jean-Yves F. Barbier
...
> À titre de comparaison avec l'Allemagne (où les achats refuseront
> purement et simplement une proposition en dessous de l'estimation
> interne et où la MOA est prêt à mettre plus de moyen à condition de
> garanties fortes de tenir les délais) qui doit obtenir des taux de
> dépassement de projet de l'ordre de 20%, en France on serait plutôt à 80%…
Ta réflexion est intéressante et correspond à mes propres retours Allemands.
Il est d'ailleurs assez inique de constater que sur les 30 dernières années,
eux ont amélioré leur situation (les français, particulièrement, les disaient
lourds, lents, trop planificateurs et pas assez déhotteurs au pied levé) en
"piquant" de la spontanéité ici; alors que dans le même temps le trait
"système-D" des français s'est amplifié au point de devenir une caricature,
sans avoir rien retiré de leurs coopérations avec nos voisins d'outre-Rhin...
--
Horse sense is the thing a horse has which keeps it from betting on people.
-- W. C. Fields
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20110918152...@anubis.defcon1
fabrice régnier
> Même mieux, sauf raisons particulières (VPN…), la conf de MySQL ne
> devrait écouter que sur lo !
f.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Aéris
Hash: SHA1
> éclaire ma lanterne. lo, c'est pas pareil que localhost ?
localhost, c'est l'adresse réseau local (127.0.0.1, ::1, …)
- --
Aeris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
ZfRcvCoBC6aZHD09Ub+B+XquyHRjlw7Mz2KADUK8t6F5nkxQ+5jIkVHL1i+C8TKB
usHyPPTseGO1FRaAPU0NR524KdQTXIUQLnoDKSm90nuQ7YKZ6Wh1JJ22GsHKm2Rk
Xtc1OzfqWQWFEksQ/tJa0xL213qlwJp864frYDoc5DDKBC+VxjdAvIs6zQuxL4AA
P+hU5xSYdjI70aMUrQjCvnUe361oSenU/DjhcMbFr/TE/3mCBd20qSiUDaOtvur+
mVHr9rtYG3or8Jxx2q26BRo/OD8kOgSx5o98GxBC5LkJfzSDm8nKE8QgsnuHqfs=
=V+G4
-----END PGP SIGNATURE-----
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
fabrice régnier
> lo, c'est l'interface réseau loopback
> localhost, c'est l'adresse réseau local (127.0.0.1, ::1, …)
Pour moi, lo, c'est le nom de l'interface (comme eth0) et localhost
c'est l'adresse de cette interface. (http://tldp.org/LDP/nag/node66.html)
Me gourre-je ?
a+
f.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Jean-Yves F. Barbier
wrote:
> > lo, c'est l'interface réseau loopback
> > localhost, c'est l'adresse réseau local (127.0.0.1, ::1, …)
> Mince, je vois pas la différence :(
>
> Pour moi, lo, c'est le nom de l'interface (comme eth0) et localhost
> c'est l'adresse de cette interface. (http://tldp.org/LDP/nag/node66.html)
>
> Me gourre-je ?
Non, mais tu devrais te relire plus souvent, ça t'éviterais de te contredire
en 3 lignes.
--
Bringing your mate to a convention is like taking a game warden hunting.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20110920100...@anubis.defcon1