Discussion :

[Michael Guilloux]

Microsoft vous accompagne dans votre migration d'Oracle vers SQL Server 2017
avec une formation et des licences gratuites

SQL Server 2017 est officiellement disponible depuis le 2 octobre et pour la première fois, le logiciel de base de données de Microsoft ne sera pas destiné uniquement à Windows, mais également à Linux.

Absent du monde Linux, Microsoft n’avait pas donné d’autres choix aux entreprises que celui d’opter pour Oracle, en ce qui concerne les SGBD propriétaires. Maintenant que le géant du logiciel propose une version de sa base de données sur Linux, il a décidé d’accompagner les entreprises dans leur migration d’Oracle sur Linux vers SQL Server 2017 sur Linux. Les organisations peuvent donc dès maintenant planifier leur migration pour bénéficier de licences gratuites, une formation gratuite et des services de migration subventionnés. Microsoft met également en avant un coût total de possession (TCO) qui ne représente qu’une infime partie de celui d’Oracle.

Il faut noter que cette offre ne s’applique pas qu'à Linux. Vous pouvez également en profiter pour migrer d’Oracle vers SQL Server 2017 sous Windows. L’offre comprend des licences gratuites, des services de support pour démarrer votre migration et accéder au cours SQL Server Essentials de Microsoft pour la formation d'administrateur de base de données Oracle. Cette offre vous permettra de découvrir les fonctionnalités clés de SQL Server grâce à des ateliers pratiques et à des démonstrations réalisées par des instructeurs, mais également apprendre à déployer vos applications sur site ou dans le cloud. En ce qui concerne les fonctionnalités de SQL Server 2017, on peut citer parmi les plus importantes :

• l’intelligence artificielle intégrée avec des analyses R et Python ;
• le calcul de score en natif dans T-SQL : une nouvelle fonctionnalité qui vous permet de calculer les scores sur les modèles de machine learning en temps quasi réel ;
• la gestion et analyse des données de type graphe ;
• Adaptive Query Processing : une nouvelle famille de fonctionnalités dans SQL Server qui apportent de l'intelligence aux performances de la base de données. Elle comprend par exemple Adaptive Memory Grants qui surveille la quantité de mémoire utilisée par une requête donnée au fil du temps pour éviter une allocation excessive ou insuffisante de la mémoire, situation qui peut affecter les performances ;
• Automatic Plan Correction : une fonctionnalité qui assure une performance continue en identifiant et en corrigeant les régressions de performance ;
• Machine Learning Server for Hadoop (ex R Server), qui apporte des analyses évolutives basées sur R et Python aux environnements Hadoop et Spark ;
• Power BI Report Server, qui offre une expérience de reporting et de tableaux de bord hybrides en vous permettant de gérer vos rapports SSRS à côté de vos rapports Power BI ;
• etc.

Il faut noter que l’offre est d'une durée limitée. La formation gratuite et les services subventionnés sont disponibles jusqu’à épuisement des stocks ou jusqu’au 30 juin 2018. Vous devez donc vous enregistrer dès maintenant pour vous assurer de bénéficier de l’offre.

Migrez d'Oracle vers SQL Server 2017 (sous Windows ou Linux) et profitez d'une formation et des licences gratuites

Voir aussi :

Pourquoi passer à SQL Server 2017 sur Linux ?
Découvrez le rapport Magic Quadrant de Gartner sur les SGBD

[kilroyFR]

L'idée est tres séduisante mais generalement ceux qui utilisent Oracle font grand usage du PL/SQL (pour codage des procedures stockées) et le gros du boulot de migration ce n'est pas tant la bascule du modele de données (se fait assez simplement) mais plutot le pb de non migration du code applicatif; et ceci est largement redibitoire (tout reecrire en C# ? le travail est colossal sur des gros projets de BDD - on a essayé et la difference de facture ne couvre pas les depenses liées au "portage" du code+tests etc).
Chez nous ca se chiffre en milliers de lignes de code.

Aussi dans ma boite on utilise sqlserver uniquement sur les nouveaux projets (lorsque pas d'existant logiciel) et que le client exige sqlserver (bon, c'est arrivé une fois en 2 ans).
Meme si sqlServer etait gratos (hors presente offre limitée dans le temps) il y aurait malgré tout des couts de migration de code comme on vend plutot a des gros clients (et non pas a des milliers de sites) du coup on fait avec les prix des licences Oracle (qui sont souvent au final derisoires rapportés au cout du projet).

[mattdef]

L'équivalent du PL/SQL en Microsoft est le T-SQL, pas le C#. Et il y a des outils pour convertir tout ça plutôt facilement. Enfin perso j'ai jamais eu de gros problême à ce niveau là

[kilroyFR]

Si je dis ca c'est que nous avons essayé et on etait tres tres tres loin de ce qu'on utilisait avec Oracle. T-SQL ca me ramene il y a 20 ans quand je faisais du Sybase donc le plus adapté c'est certainement plus le C# que T-SQL. Je te parle de 10aines de milliers de code avec utilisation de la plupart des packages DBMS_xxx Oracle (pour lesquels il n'y a pas d'equivalents en T-SQL d'ou l'idee de refaire les equivalents en C# - T-SQL avec ses syntaxes barbares ca te fait devenir aveugle au bout d'une page de code avec tous les symboles cabalistiques du langage).
Je serai curieux de connaitres tes outils miraculeux; je pense que ca tient plus de l'anecdote qu'autre chose (ou alors c'est que tu ne connais que vaguement PL/SQL).
J'ai fais les 2 (Oracle depuis 1997 et SqlServer depuis plus de 2 ans).
Meme PostGreSql en fait un argument de portage depuis Oracle mais en pratique c'est du marketing car seule une infime partie des packages equivalents existent (solution PostGre qu'on a abandonné egalement).

[mattdef]

J'ai souvent eu à porter des procédures stockées et des fonctions d'Oracle vers SQL Server et comme je le disais, je n'ai jamais eu de gros souci avec ça.
Après je ne suis pas un expert Oracle et je n'ai peut être jamais eu à faire à des BDD complexes "progammaticalement" parlant.
Pour moi, une bonne BDD, c'est le strict minimum de logique métier, uniquement sur des points critiques en terme de performance. le reste doit être fait dans le programme.
Mais je me trompe peut-être...

[dfiad77pro]

Bonne chance pour automatiser cela si les procs oracles utilisent des Types Tableaux avec des %TYPE %ROW (les références sur un type n'existent pas à ma connaissance sur SQL_SERVER ).

En tout cas sur les bases complexes, c'est pas si évident, notamment si tu utilise l'EBR (Edition multiple). Et ensuite faut se méfier des différences de plan d'exécution/optimiseur ... Bref nous on a une base avec 700 000 lignes de PL/SQL multi-éditionné, 50 schémas...

En effet on a énormément de métier dedans, c'est un choix de conception (y'a des gens qui militent pour ) :

Pour moi, une bonne BDD, c'est le strict minimum de logique métier, uniquement sur des points critiques en terme de performance. le reste doit être fait dans le programme.

Dans un service à la rigeur??
Pour moi l'embarquer dans le programme n'est pas toujours une bonne idée sauf dans les cas suivants :
- Pas de besoin d'aller retour entre la base et le clients
- Algo style tableur ou il est nécessaire de calculer à chaque saisie ( pour ensuite pousser le résultat vers la base)
- Tout autre algos ne nécessitant pas de base ( compression vidéo, hors ligne etc..)

[frfancha]

Pour moi, une bonne BDD, c'est le strict minimum de logique métier

Oui, ben alors pas du tout justement. Tout doit être dans la DB, cela permet d'attaquer la même logique d'où que ce soit.
Et s'il y a bien un truc qui est pérenne dans le temps c'est bien SQL, alors les techniques qui construisent les couches auour changent tous les 3 ans

[mattdef]

Je ne suis pas d'accord. Je sais d'expérience que l'on attaque jamais la même logique justement. Ou alors c'est un besoin très rare.

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?

[kilroyFR]

Une requete SQL (CRUD) vers une BDD est l'equivalent d'une requete (WS) qu'on ferait vers un serveur web pour MAJ/inserer/supprimer/recuperer des données.
(On est juste une couche au dessus dans le cas des WS alors que la couche metier est plutot tres proche voir fusionnée avec le moteur BDD. Donc fondamentalement rien de revolutionnaire dans les WS).

quand tu codes un WS il fournit un service qui potentiellement peut etre utilisé a l'identique par beaucoup d'autres consommateurs (SOA).
Avec la BDD ca n'est pas different; juste pas les memes technos employées.

[martopioche]

Depuis ces dernieres années et avec le nombre grandissant de dev C# qui ne voient la BDD que comme du simple stockage (enfin tous les nouveaux rentrés chez nous en tout cas), la conception s'est transformée en 'on met toute l'intelligence/metier' hors de la BDD dans du C# parce que c'est mieux pour les tests unitaires (coder des tests unitaires en PL/SQL c'est pas sexy...).

Conclusion (les WS et autres passent leur temps a lire/ecrire des volumes de données considerables pour les stocker/mapper dans des objets C# (representation memoire a l'identique des tables) - ils en sont arrivés au point de selectionner des volumes et tout faire les tris/filtres etc. localement sur le client.
Bref le boulot et l'intelligence se retrouve deplaces dans une couche WS et ce que fait habituellement la BDD (cache, controle intégrité, tri etc) est réalisée dans le code C#...
Bref pour la plupart des anciens, c'est un non sens (d'ailleurs on le voit au niveau des perfs/charges reseau c'est catastrophique - merci SOA).
La BDD est presque du luxe a ce niveau; de simples fichiers a plats seraient suffisants.

ça y est, ça aussi fallait le copier de Java ? Oh désolé, mais en effet, ça fait plus de 10 ans que j'avais commencé à le voir là bas… Je dirai quand même que c'est révélateur d'une organisation où on se dit qu'un dev remplace un expert données/DBA, mais comme il ne connait rien aux bases de données, tout se fait dans le code…

Je ne suis pas d'accord. Je sais d'expérience que l'on attaque jamais la même logique justement. Ou alors c'est un besoin très rare.

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?

La première aberration que j'ai vu… En fait, non, la formulation exacte est "l'aberration que l'on voit en permanence" est l'absence d'une notion de base comme l'intégrité référentielle (les clauses ON DELETE par exemple). Ces directives doivent être dans la base car elles sont garantes de la cohérence des données.

On n'attaque peut être pas la même logique entre applis, mais les règles métier ne changent pas. Les cas où on a besoin d'utiliser la même logique, c'est lorsqu'on a des règles métier et des données structurées. Quand on ne sait pas ce que l'on fait et que les données sont sans importance, là…

[kilroyFR]

Dans le genre de derive entre des devs orientés BDD et les autres, le cas du JSON. Dans le genre des dernieres demandes : passer a MongoDb car 'on n'a pas a s'emmerder a definir des structures fixes et en plus on stocke le json tel quel depuis le C#; y a rien a faire'...
Voila le genre de comportements qu'on doit subir ces dernieres années.

2 façons de voir le monde... (la verité c'est qu'en prod ils galerent - alors les pbs ne sont jamais dans le code mais dans la BDD (Oracle c'est de la merde, il faut mongo db ou hadoop), l'infra est pourrie (reseau GB pas suffisant), machines savec peu de RAM (16Go de RAM tu fais rien etc....).
C'est malheureusement cette seconde ecole qui, ramenant avec elle tout un vocabulaire 'sexy' pour des managers, a le vent en poupe. Si c'est pas malheureux...

[dfiad77pro]

Y'a aussi un peu les temps de dev ridicule qu'on nous alloue parfois :


Par exemple coté .NET , coder une requête complexe avec Entity Framework est beaucoup plus rapide que de :

- Créer les types complexe oracles/sql server et la procédure stockée
- Effectuer le binding manuel coté C# sur les types complexes (non géré en scaffolding) dans le service ou l'application


Par contre :
- Les performances ne sont pas toujours au rendez-vous ( perso je suis dans une grosse boite et je doit tout me taper, le front, le back...)
- Si vous devez taper dans plusieurs schéma c'est mort ( on maitrise moins les requêtes inter schéma)
- Type complexe (tableaux UDT) en entré + provider oracle managé = incompatible.


Deux trucs que j'aime pas trop dans le PL/SQL :
- on se retrouve vite avec des packages très volumineux genre 5000 lignes de code la ou les normes java /C# demandent de séparer en classe de 1000 lignes grands max.
- chaque boites à ses propres normes (comme tout les langages, mais c'est encore plus poussé je trouve)

[SQLpro]

Je ne suis pas d'accord. Je sais d'expérience que l'on attaque jamais la même logique justement. Ou alors c'est un besoin très rare.

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?

Attendez d'avoir un peu d'expérience et on en reparlera....

A +

[SQLpro]

Tout est dans le titre !

http://fil.cigref.fr/_upload/documen...cle2017-Fr.pdf

A +

[martopioche]

Dans le genre de derive entre des devs orientés BDD et les autres, le cas du JSON. Dans le genre des dernieres demandes : passer a MongoDb car 'on n'a pas a s'emmerder a definir des structures fixes et en plus on stocke le json tel quel depuis le C#; y a rien a faire'...
Voila le genre de comportements qu'on doit subir ces dernieres années.

Ouiii !!!
Et le temps qu'on perd à rappeler que le No de NoSQL ne signifie pas No mais Not Only… Là faut attendre que l'interlocuteur récupère du segmentation fault que vient de faire le cerveau…

C'est malheureusement cette seconde ecole qui, ramenant avec elle tout un vocabulaire 'sexy' pour des managers, a le vent en poupe. Si c'est pas malheureux...

Ce n'est pas que le vocabulaire mais également une promesse de gain d'efficacité avec comme preuve que l'usage actuel ne marche pas. Le tout appuyé par le fait que tout le monde en parle et que les références disent qu'ils le font (Facebook gère ses données en NoSQL, Nokia a publié un rapport comme quoi Scrum marche trop bien, le consultant nous a dit de…)

P.s. je met des smiley , mais c'est bien parce que je m'en suis éloigné, lorsqu'on est dedans,

Y'a aussi un peu les temps de dev ridicule qu'on nous alloue parfois :


Par exemple coté .NET , coder une requête complexe avec Entity Framework est beaucoup plus rapide que de :

- Créer les types complexe oracles/sql server et la procédure stockée

Rien que sur ce point là, on est d'accord que c'est volontairement que vous vous mettez le couteau sous la gorge. Car pour le projet suivant de l'autre équipe qui fait du Java, on est d'accord que vu qu'ils utilisent le même "type complexe" que vous, vous avez déjà la partie en base, je n'ai qu'à chiffrer la partie définition de l'objet et mapping et leur imposer un délais en conséquence…

- on se retrouve vite avec des packages très volumineux genre 5000 lignes de code la ou les normes java /C# demandent de séparer en classe de 1000 lignes grands max.

J'aime bien cette norme… "Grand max"… Donc il doit y avoir un "petit max", il est de combien ? Et pourquoi le grand plutôt que le petit ?
Et puis bon, grand max, si j'en suis à 1001, ah bah plus haut là où j'ai décomposé en 5 appels de méthodes, en fait, je peux faire du one liner à la Perl… Et pas que là, oué…

Développer en objet poussent à développer la partie métier sur la couche client car "normalement ", on peut attaquer différentes Bases de données.

Je ne vois pas le rapport entre "développer en objet" (ça veut dire quoi ? Développer en créant des objets comme avec Java ? Développer selon les principes de la POO ? ) et le fait de pouvoir ainsi "attaquer différentes bases de données". En procédural ou fonctionnel, ce n'est pas possible à envisager ?

Et "on peut"…*Mais est ce que dans la pratique tu a plus de projets qui ont plusieurs applicatifs nécessitant la même base de données ou plus de projets qui nécessitent plusieurs bases d'éditeurs différents (car sinon, tu déploie la même procstock/schéma/contraintes/vues sur les différentes du même éditeur) ayant le même schéma ?

2/ normes de codage c'est souvent fortement inspiré des regles de codage du fournisseur du langage (avec d'eventuelles adaptations; genre prefixer les noms de variables etc en fonction des regles dans l'entreprise).

J'aurai tendance à dire que ça vient surtout du suivi des modes… Et de l'historique de la boite. Quand on voir comment la PEP8 de Python est accueillie dans les boites où beaucoup de normes sont en contradiction…

[martopioche]

La je vois surtout des sysdba qui défendent leur bout de gras.
Même niveau que des pro "tout logiciel".

Mais toute cette discussion résulte de querelles de chapelles (db/dev) et le plus généralement de devs qui défendent le "tout logiciel" (parce qu'il est plus courant d'avoir des devs que des dba).

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.

J'estime que la règle de base est que la BDD est la garante de la cohérence des données. Cette cohérence est définie par le métier et la définition de cette cohérence est une partie du métier. Ne pas déléguer à la BDD la gestion de la cohérence (cf par exemple les ORMs avec l'intégrité référentielle) est un non-sens. Pour le reste du métier, on se rejoins.

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.

Ce qui est intéressant, c'est que régulièrement, cette critique vient d'une mauvaise stratégie d'accès à la base…

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.

Même sans aller jusqu'aux cas "extrêmes", une compétence BDD (plus poussée que savoir installer MySQL et un ORM) est toujours indispensable…

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^^).

Malgré mes quelques remarques :

En SOA/micro service on a tendance a faire le contraire chez nous.
Chaque micro service fait une chose simple; par contre toute la logique que tu stockerais dans la BDD et avec les benefices en terme de perfs (les données ne sortent pas de la base), ben tu les perds car les API passent leur temps a faire des lectures/ecritures unitaires sur la BDD (entree/sortie de données via http c'est tres couteux !).
On le vit au quotidien ces derniers temps puisqu'on nous a imposé les micro services.
Resultat, la ou avant on mettait 20 min pour importer un fichier de topologie de reseau + traitement dans BDD (dispatch metier), en micro services (puisque le dispatch metier des données dans les differentes tables du modele), cela prend... 3h ... et on attribue les pbs au reseau, bdd (manque de pot on a la solution precedente qui prouve le contraire).
Pour moi c'est une histoire de curseur à placer au bon endroit.

Pour un problème similaire, Google a su imposer la bonne pratique sur AppEngine : ils ont augmenté la tarification des lectures/écritures… C'est dingue comment un dev peut être inventif quand on ajoute le paramètre du portefeuille…

C'est pas trolldi, mais bon .
Généralement, les éditeurs de bases de données vous expliquent que mettre la logique métier dans des procédures stockées, c'est bien.
Ils savent bien que pour changer de produit (c'est à dire aller à la concurrence), ça nécessite des doubles compétences et une requalification complète des applications.
Donc des couts trop importants, par rapport au gain espérer (c'est à dire le prix des licences).

Et quand un éditeur de logiciel te vends la logique métier en code, le principe est le même, ce qui est critique est emprisonné dans une techno que tu ne changera pas au risque de remettre en cause la fiabilité de ton système. Et plus généralement, c'est valable pour tout (vu pour les ESBs aussi…)

Et puis le mapping verticale (1 table, 1 objet), c'est pas forcement la bonne idée.

Alors celle-là, en effet, c'est l'idée la plus stupide dans un projet… Un objet est une entité de traitement, une table une entité de stockage de donnée. On devrait pouvoir virer pour faute grave celui qui pense que c'est la même chose.[/QUOTE]

[aieeeuuuuu]

Bonjour,

Dans quel cas avez-vous besoin que plusieurs applications différentes utilisent la même logique d'une BDD ?

1/ création d'une appli web en plus/remplacement du client lourd, ou création d'une appli mobile, ou combinaison de tout ça
2/ refonte de l'appli existante souvent dans un autre langage plus à la mode
3/ appli tierce qui doit accéder aux données / appli développée dans un coin pour un besoin marginal, non développée par le SI mais par le stagiaire qui n'est pas forcément informaticien (et même si c'est le cas, quand on voit la formation en SQL dans les cursus informatiques...) et qui ne connait pas la notion de jointure : ça fournit une interface toute prête, ça lui simplifie le travail (pas besoin de comprendre le modéle relationnel) et ça assure au DBA qu'il n'y aura pas de requetes sauvages lancées directement s

Mais selon moi, un des plus gros avantages à mettre la logique métier dans la BDD, c'est qu'ainsi, on maitrise bien mieux les requêtes qui vont être exécutées sur la base. Pour le tunning, c'est un sacré avantage : vous pouvez modifier une requête pour la rendre plus performante sans impacter qui que ce soit. ça évite aussi les requêtes monstrueuses générées par les ORM, pour lesquelles il faut des écrans de 372 pouces. Bref, vous maitrisez tout ce qui rentre et qui sort de la BDD et ça facilite grandement l'administration/optimisation.

Bien sûr, cela demande des compétences en SQL, et s'est souvent là que le bat blesse.

Bien sûr aussi, il ne faut pas être intégriste de cette solution et savoir déporter un traitement lourd, afin d'éviter une charge importante inutile au serveur de BDD qui sont plus difficiles a "scaler-out" que des serveur applicatifs. Je pense à des problématiques couteuses en CPU pour lesquelles le SQL n'est pas forcément le plus adapté, comme des problèmes NP Complets voire des manipulations massives et complexes de chaines de caractères,...

[crevecoeurj]

Développer en objet poussent à développer la partie métier sur la couche client car "normalement ", on peut attaquer différentes Bases de données.

Intéressant selon la nature des projets bien sur.

[ManyTwo]

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]

[kilroyFR]

Personnellement je ne suis pas particulierement pro l'un ou l'autre puisque je travaille sur les 2 niveaux; ce qui me gene plus c'est la tendance naturelle des nouveaux devs (hors BDD) a ne prendre qu'une approche pur logiciel sans regarder si la BDD ne serait pas mieux adaptée dans certaines situations (souvent meme entendu, que SQL c'est compliqué... mais les memes font du Linq en C# avec une syntaxe proche de SQL... va comprendre).

Par exemple on n'utilise pas la BDD pour mettre a dispo des WS (oracle le permet notamment) mais on repousse dans le C# via WS traditionnels (qui peuvent appeler du PL/SQL si la logique de traitement concerne pas mal de traitement de données).

En SOA/micro service on a tendance a faire le contraire chez nous.
Chaque micro service fait une chose simple; par contre toute la logique que tu stockerais dans la BDD et avec les benefices en terme de perfs (les données ne sortent pas de la base), ben tu les perds car les API passent leur temps a faire des lectures/ecritures unitaires sur la BDD (entree/sortie de données via http c'est tres couteux !).
On le vit au quotidien ces derniers temps puisqu'on nous a imposé les micro services.
Resultat, la ou avant on mettait 20 min pour importer un fichier de topologie de reseau + traitement dans BDD (dispatch metier), en micro services (puisque le dispatch metier des données dans les differentes tables du modele), cela prend... 3h ... et on attribue les pbs au reseau, bdd (manque de pot on a la solution precedente qui prouve le contraire).
Pour moi c'est une histoire de curseur à placer au bon endroit.
Autre exemple lorsque Oracle a sorti ses packages pour manipuler du XML, on a essayé mais finalement laisser tomber; pas le role de la BDD de valider des schemas quand c'etait plus simple/adapté de le faire depuis l'appli C# (analyse/parsing puis 'insert into database' betement).
C'est plus cette façon de vouloir generaliser a tout prix qui est destabilisante de nos jours. Comme si la nouvelle techno/nouveau langage allait resoudre tous les pbs.

Concernant les outils de tests unitaires on en utilise sur Oracle (equivalent de NUnit mais en PL/SQL) - il existe du payant et du gratuit qui est largement suffisant.