La je vois surtout des sysdba qui défendent leur bout de gras.
Même niveau que des pro "tout logiciel".
Dire que mettre la logique métier dans la base est une règle fondamentalement meilleure est un non sens, tout comme dire l'inverse.
Il y a du pour est contre des deux cotés, suivant les projets on va privilégier différentes choses...
Déjà suivant le moteur de base de données, cela peut complètement changer la donne.
Dans mon entreprise actuelle (15aine d'employés), historiquement la logique métier est en BDD (interbase).
Le logiciel principal un ERP spécialisé, gérant des fonctionnements métiers complexes.
Et bien cela commence à poser de sérieux soucis.
De fiabilité du code:
Aucun test automatisé (donc aucune répétition en cas de changement), faire des tests unitaires sur des BDD reste plus compliqué à faire (aucun outil pour Interbase en tout cas).
De performance:
Pourtant à première vue les SGBDR sont optimisés et performants, mettre du code dedans est une bonne idée. Mais ne pas décharger une partie de la logique en amont peut nuire aux performances.
Quand pour des calculs pour arriver à un état final oblige à beaucoup de mises à jour de tables, pour relancer des triggers qui calculent, réécrire n fois les mêmes valeurs et bien on arrive à surcharger la base. Même si les SGBDR optimisent l'I/O et l'accès mémoire.
De scalabilité:
si besoin de répliquer le code métier, notamment la puissance de calcul, pas le choix: il faut faire du load balancing sur la base. Donc réplication. Donc compliqué, surtout lorsque qu'arrive les mises à jours du code métier.
De limitation de code:
Les SGBDR ne sont pas prévus à la base pour la même chose que les language de développement.
C'est complémentaire et non en compétition, comme vous voulez le faire croire. Comment tu gères le mutli threading dans ton code pour faire du calcul parallèle? Peut être qu'oracle a des solutions, la plupart des SGBDR, ou des gens qui font du SQL coderont en procédural mono thread.
Alors bien sur il y a des solutions pour limiter chaque impacte j'imagine, encore faut t'il y avoir des experts BDD qui ont le temps de se pencher sur l'optimisation des procédures de chaque dev etc.
Ici je met en avant certaines contraintes qui nous posent problème, mais il y a beaucoup de points positifs pas de soucis la dessus. Le but est de démontrer qu'il n'y a pas de règle universelle, et surtout qu'il faut arrêter de voir le code BDD et le code logiciel comme des concurrents.
Le but est de trouver un équilibre, qui satisfera les critères importants du projet (pas des équipes, du projet en général hein^^).
La performance? Maintenabilité? scalabilité? Compétences en interne et sur le marché (souvent négligé...)? Fiabilité et intégrité des données (le NoSql montre bien que certains projets ne necessistes pas une intégrité forte)?
[troll /on],Finalement le discours des "pro DB" est aussi limité que celui des "pro logiciel": "C'est mon coté qui est mieux d'abord"! [troll /off]
Partager