-----BEGIN PGP SIGNED MESSAGE----- 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-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4e747c0b$0$973$426a7...@news.free.fr