test unitaire, migrations, et thick database

Version imprimable

29/12/2010, 10h39
fourchette

test unitaire, migrations, et thick database

bonjour,

je suis en train de creuser le concept de "thick database". J'y vois des avantages et des inconvenients.

L'avantage principal étant surtout d'éviter tous les écueils d'une appli reposant trop sur un ORM, dont la plupart ont soit des pbs de maturité, soit des problemes de kilo de xml à gérer, soit des problemes de perfs, le plus souvent tout ca à la fois.

Ce qui me gene en l'état de mes lectures, c'est que je n'ai pas encore compris :
* comment gérer les changements de version d'un état x de la structure de database à un autre ? (par exemple, les migrations de rails résolvent cette problématique avec élégance)
* comment gérer les tests unitaires d'une procédure stockée (ou tests de comportements type rspec, voire torture de test comme heckle) ?
à ce stade, mis à part recharger la base dans un état X depuis un script hors SGBD, puis modifier et interroger les vues depuis de meme script de test, je ne vois pas comment résoudre ca. et meme cette "solution de contrournement" est un test fonctionnel pas un test unitaire.

j'ai bien lu la partie #6 des règles de codd telles que décrites par sqlpro mais me laisse un gout spécial, je trouve surtout le code peu lisible, peu éléguant et je ne comprends pas comment automatiser le processus de test (mon ignorance ss doute)

a travers ca, c'est tout l'aspect de l'agilité qui m'interpelle (comment gérer les sources des modifs de base et de procédures stockées, de triggers, etc. comment ca s'interfacer avec svn/git, comment je vais mettre en prod mes modifs automatiquement, comment je vais lancer mes scripts de test et de qualité du code via mon server d'intégration continue, etc.

Quelles solutions de gestion des migrations et gestion des tests uniaires avez-vous mis en place dans le contexte d'un systeme "thick database" donc avec la majorité du coté métier géré directement dans le SGBD ?

J'avoue que la réponse m'interesse sur plusieurs SGBD, mais pour l'exercice et puisque MS SQL Server semble en avance là dessus, je voudrais regarder ce que MS SQL Server a à proposer dans ce domaine et surtout votre propre retour d'expérience là dessus

merci
01/01/2011, 17h05
SQLpro

Citation:

Envoyé par fourchette

* comment gérer les changements de version d'un état x de la structure de database à un autre ? (par exemple, les migrations de rails résolvent cette problématique avec élégance)

Un outil de modélisation de bases de données comme Power AMC est là pour ce faire. A partir de modèles de données archivés, il permet de réaliser le script différentiel.

Citation:

* comment gérer les tests unitaires d'une procédure stockée (ou tests de comportements type rspec, voire torture de test comme heckle) ?

Il n'y a pas de solution miracle. Il faut passer par un test applicatif et non pas un test purement SQL.

Citation:

a travers ca, c'est tout l'aspect de l'agilité qui m'interpelle (comment gérer les sources des modifs de base et de procédures stockées, de triggers, etc. comment ca s'interfacer avec svn/git, comment je vais mettre en prod mes modifs automatiquement, comment je vais lancer mes scripts de test et de qualité du code via mon server d'intégration continue, etc.

Par l'outil de modélisation qui peut archiver tout ce qui est objet de la base :
procédures trigger et fonction comprises.

Citation:

Quelles solutions de gestion des migrations et gestion des tests uniaires avez-vous mis en place dans le contexte d'un systeme "thick database" donc avec la majorité du coté métier géré directement dans le SGBD ?

Des tests automatisés d'application et non de bases de données, comme vous le feriez avec n'importe quel autre développement. Le fait que le code soit dans la base ne change rien à ce que les IHM font !

A +
04/01/2011, 13h57
fourchette

merci pour le feedback

limiter les tests à des tests d'intégration ne me plait pas beaucoup. ca implique que les tests seront long à effectuer (supérieur à qqs secondes), donc le délai entre l'introduction d'un bug et sa détection automatique risque d'augmenter. ce qui n'est pas bon pour mon cout.
de plus, dans la durée tout ce qui est une gene pour mes developpeurs a tendance à ne pas etre fait.

sans parler que dans ce contexte "tester les tests" me parait couteux aussi.

Apres sur Power AMC... j'aurais beaucoup de mal à faire confiance à un outil qui calcule tout seul le "diff" entre deux structures de base. peut-etre dois-je tout simplement me renseigner sur la technique employée par un tel outil.

simplement ce que j'ai du mal à comprendre à ce stade c'est comment les programmeurs sql s'interfacent avec du git/svn/perforce et gèrent leur travail en commun (branches/tags/trunk). qui dit code metier dit code quoi :)

il faut que je creuse davantage on dirait
04/04/2011, 14h28
fourchette

juste un petit feedback sur ce post

donc j'ai tenté l'approche thick database sur un projet existant php/mysql

il s'agissait surtout d'ajouter des fonctionnalités de reporting à un projet legacy existant (et non vu le contexte des outils comme pentaho qui avaient pourtant ma préférence n'étaient pas la meilleure option pour le client final)

bref, on y est allé pour du thick database, cad avec la logique métier calculé par le SGBD

démarche:
* le tout posé dans des fichiers *.sql maintenus à coté des fichiers *.php le tout dans svn comme il se doit. pas de Power AMC ici. des plugins eclipse affichent des diagrammes mais perso je trouve ca une nuisance pas une aide.

* on a eu une (petite) partie du code applicatif (php) à migrer en code mysql. De toute facon ce code légacy étant assez dégueulasse on ne pouvait pas le toucher sans casser qqch. Donc il a fallu le passer au phpunit juste pour enregistrer le comportement attendu selon telle ou telle entrée (on a d'ailleurs levé un tas de bugs..)

* ensuite on a fait des fonctions et procédures stockées mysql pour immiter le code existant, ce code a été passé au script phpunit en TDD, puis on a réutilisé les scripts de test de l'étape 1 pour s'assurer que le nouveau morceau de code remplacant le bout de code existant n'introduisait pas de regression

* on a ajouté le reste du code métier necessaire aux nouvelles fonctionalités dans mysql, le tout couvert par phpunit

au final, on a pu réutiliser ce code métier dans la database dans plusieurs contextes (php / macro excel). on a également un très net gain en perf (de plusieurs minutes à qqs sec, il faut dire que la partie existante était crade)

cette approche me laisse confiant au final. je regrette que certains tests soient du coup longs à executer (recharger un dump complet de base et massivement tester certaines fonctions. tt compris dans les 30s pour 4300 assertions)

Par contre, gros point noir sur mysql qui n'est clairement pas fait pour ca. Les limitations intrinsèques de ce sgdb sur les functions/triggers/stored procedure rendent le code tres verbeux et vraiment peu élaguant. De plus, il y a pas mal de répétitions je trouve (les triggers par exemple, le fait de ne pas pouvoir donner simplement des valeurs par defaut, etc.).
Et surtout quel choc => revenir à du code procédural apres tout ce temps, par rapport à du code objet il y a bcp de perte de fonctionnalités :
* librairies perdues notamment,
* pas de refactorisation SQL dans l'IDE (eclipse ici, mais pareil pour les autres je pense),
* code SQL pas DRY du tout du tout, c'en est choquant parfois
une declaration de fonction prend 4 ou 5 lignes (DELIMIER je te hais)pas de debugger digne de ce nom (tres tres genant par moment, meme lorsqu'on est couvert par du test unitaire)
* pas de function/procédure stockée récursive à moins de toucher à la conf du server
* justement pas de test unitaire, il faut appeler ses fonction avec un autre language ayant des libs de test (ici du "select mafonction(10)" ou du "call maprocedure(12345)")

==> certes la plupart de ces reproches s'adressent à mysql au final (peut-etre on peut esquiver plusieurs limitations mysql avec qqch de plus sérieux comme mssql, oracle, postgresql, etc.)

c'est moins sympa que j'espérais au départ, mais globalement c'est plus positif que négatif :)
04/04/2011, 17h22
SQLpro

Le problème est que vous avez utilisé le plus mauvais SGBD, même pas relationnel (MySQL ne sait toujours pas faire des requêtes ensemblistes et en reste toujours au ligne à ligne.... voir l'exemple de la règle de Codd n°7 dans http://sqlpro.developpez.com/SGBDR/R...egles_codd.pdf)
1) pas de vues exploitables (il ne sait pas les simplifier, voir l'article de MikeDavem sur l'optimisation par les contraintes : http://blog.developpez.com/mikedavem...e-sur-les-per/)
2) trigger inexploitable vus leurs limitations
3) pas de trigger INSTEAD OF
4) pas possibilité de factoriser le code des requêtes par des CTE
5) pas de vues indexées
6) indexation plus que pauvre en comparaison des SGBDR (lire : http://blog.developpez.com/sqlpro/p9...t-sur-l-index/)
5) performances largement immondes dès que l'on compare avec n'importe quel vrai SGBDR (lire : http://blog.developpez.com/sqlpro/p9...lles-en-sql-1/)

J'ai du mal à comprendre cet acharnement à vouloir faire du MySQL, qui de plus n'est ni open, ni gratuit, alors que vous avez d'excellent SGBDR comme PostGreSQL ou SQL Server Express qui sont l'un ouvert et gratuit, l'autre gratuit et très haut en gamme !

En tout cas, bravo pour ce retour d'expérience. Pour ma part, j'ai observé des gain de prod jusqu'à x2 et de perf, incommensurable (x 1000).
Jetez un coup d'œil sur les dégradations des perf liés aux ORM, sur http://ormeter.net/ par exemple dans le tableau 2, on observe que NHibernate met 24 fois plus de temps pour un simple UPDATE que la requête directe... Or un UPDATE bloque de manière exclusive, ce qui fait qu'au finish LECTURE + ECRITURE sont bloquées !!!! Bref, il n'est pas rare de multiplier par 1000 les performances globales en shuntant les ORM !!!

A +
06/04/2011, 14h39
fourchette

Citation:

Envoyé par SQLpro

Le problème est que vous avez utilisé le plus mauvais SGBD

effectivement le choix de mysql est contestable. je ne l'aurais pas choisi et d'intuition je sentais qu'il était la cause des points negatifs vécus.

mais il faut dire que l'appli sous jacente (php) s'appuie très lourdement sur du mysql_connect(), donc impossible de changer de SGDB sans changer toute l'appli (en grande partie en tt cas). ce qui était inenvisageable vu le budget et le scope de ec "projet".

apres, on s'est demandé aussi pourquoi ne pas faire un import dans postgresql ou ms sql des datas de prod (genre ttes les heures) et travailler plutot sur cette base
parmi les points qui ont pesé negativement sur ce choix
* impose d'admnistrer un autre server (mm sqlexpress, parfois on a besoin d'un admin, ne serait-ce que pour les backups et les catastrophes), donc + de boulot en administration
* profil disponibles coté administration ni bien formés, ni bien motivés (on adapte une solution à une équipe aussi)
* bcp de data à faire transiter, mysql à genoux pdt le transit, ca se "sent" sur les utilisateurs pdt le transfer. et les options pour faire disparaitre cette mini-nuisance (ex: mysql en conf master-slaves, puis on aspire les datas depuis du slave) étaient un peu trop à demander à l'équipe admin je pense (charge de l'equipe + competences)
* profils dispo pour coder du sql métier n'avaient pas vraiment la motivation (et j'aime pas tirer des mulets quoi)
* de toute facon, on voulait virer du code pourri existant, ce que n'aurait pas permis ce SGBD "secondaire mais mieux"

c'est surtout le point 1 qui a pesé lourd (introduction de complexité).

Citation:

J'ai du mal à comprendre cet acharnement à vouloir faire du MySQL, qui de plus n'est ni open, ni gratuit

ahh le legacy... ca pèse lourd. il y a 10 ans certes postgresql etait déjà là mais mysql avait plus la coté et etait vraiment gratuit et ouvert il me semble :)

pour conclure il est apparu clairement qu'il valait mieux se bouffer du mysql pour ce mini projet.

merci pour les liens, je vais les regarder attentivement
06/04/2011, 18h13
SQLpro

Citation:

Envoyé par fourchette

parmi les points qui ont pesé negativement sur ce choix
* impose d'admnistrer un autre server (mm sqlexpress, parfois on a besoin d'un admin, ne serait-ce que pour les backups et les catastrophes), donc + de boulot en administration

Ca c'est faus. MySQL est bien pluis difficile à administrer et peu auto configurable par rapport à du SQL Server on l'on peut faire fairetoutes les tâches importante d'admin, par un bent qui sait au moins se servir d'un mulot !

Citation:

* profil disponibles coté administration ni bien formés, ni bien motivés (on adapte une solution à une équipe aussi)
* bcp de data à faire transiter, mysql à genoux pdt le transit, ca se "sent" sur les utilisateurs pdt le transfer. et les options pour faire disparaitre cette mini-nuisance (ex: mysql en conf master-slaves, puis on aspire les datas depuis du slave) étaient un peu trop à demander à l'équipe admin je pense (charge de l'equipe + competences)
* profils dispo pour coder du sql métier n'avaient pas vraiment la motivation (et j'aime pas tirer des mulets quoi)
* de toute facon, on voulait virer du code pourri existant, ce que n'aurait pas permis ce SGBD "secondaire mais mieux"

Pour le reste c'est avant tout la formation qui malheureusement est très médiocre en matière de SGBDR.
Les développeurs d'aujourd'hui ont notablement régressés sur l'écriture des requêtes, la compréhension des transactions, par rapport à il y a quelques années.
En pratique, dans les cours des écoles d'ingé comme dans les université on accorde de moins en moins de temps qu SGBDR. Même les prof des autres matières sont archi nuls. Là je vais devoir faire dans 8 jours une conférence état de l'art des SGBDR dans une des écoles d'ingénieurs dans laquelle je donne des cours, aux.... profs !!!! En effet, la plupart d'entre eux considèrent qu'un SGBDR ne fait que du stockage et ont une vague idée de ce que sont les contraintes et les index.... Quand au fonctionnement d'un optimiseur...
Prenons par exemple l'excellent article de MikeDavem, montrant l'optimisation par les contraintes dans SQL Server : http://blog.developpez.com/mikedavem...e-sur-les-per/ (évidemment, MySQL est à mille lieues de savoir faire cela !).

C'est là le vrai point sensible...

A +