Bonne pratique pour developpement

Bonjour
j'ai entendu parler et j'ai lu beaucoup de post concernant les bonnes pratiques des développeurs autour des SGBD mais vu que je ne suis pas expert de domaine je souhaite le valider avec vous.
Dans l'un des nouveaux projets que nous allons entamé le DBA de mon client exigence que le code soit sous forme des routines SQL
- pas de lectures et d'écriture directement sur les tables (uniquement des views)
- toutes les requêtes sont sous forme de procédures stockés (select, update insert et delete)
- posé toutes contraintes du métiers au niveau de la base de données (contrainte check)

Mais je trouve que peut être ca va compliqué un peu les développements sur tout au niveau du versionning de l'application et du déploiement (surtout que nos développeurs ont l'habitude de tout gérer dans le code de l'application même pour l'évolution de la base ils utilisent Entity Framework Code First)

Que pensez vous ?

Merci
A+

Je pense que le client à raison de vouloir une indépendance entre la partie code propriétaire et code de gestion des données.
Avec cette méthode il se laisse la liberté de migrer ses données vers un autre SGBD, ou de les rendre accessible pour d'autres développements hors galaxie Microsoft.

Son cahier des charges semble conforme aux standards architecture MVC ou MVVM, ce qui est tout de même le B.A.BA. des bonnes pratiques

Bonjour,

Le DBA a en partie raison, car en réalisant cette méthode il peut garantir les performances du SGBD, toutes les requêtes sont codés coté SGBD et ne sont pas fournis par un ORM qui va auto généré des requêtes potentiellement mauvaise ou mal adapté en fonction du besoin.

Grace a cette pratique qui peut s’avérer contraignante pour le développeur il va aussi garantir un niveau d'exigence au niveau des développements ce qui au départ pourra paraître contraignant permettra de gagner du temps lors de mise a jour par la suite.

Tout est une question de point de vu, mais globalement pour avoir fait des audits sur des retours d’expérience ORM, si l'architecture base de données et le modèle réalisé de base de données a été pensé que coté développeurs, je peux garantir que coté maintenance nous avons pu avoir quelques frayeurs pour récupérer le tout et surtout de gros problèmes de performances qui peuvent entraîner des interruption de services ou il faut intervenir en pleine nuit sur la production pour essayer de trouver un palliatif ...

Bref pour le coup, il est peut être très restrictif, mais si on se contente d'écouter stricto sensu les bonnes pratiques des SGBD il a raison.

:aie::aie:
donc ça remet en cause tout nos développement (une ignorance totale de la partie SGBD, tout est géré par des ORM)

ouai, désolé :mrgreen:
le concept ORM à vécu.
son gros défaut c'est d'être propriétaire.
De l'autre coté les SGBD ne sont pas aussi interchangeables qu'on le voudrait, mais les différences ne sont pas dramatiques.
Alors que changer d'ORM, ça coûte vraiment beaucoup trop cher

Citation:

---

Envoyé par erpWorld

Bonjour
j'ai entendu parler et j'ai lu beaucoup de post concernant les bonnes pratiques des développeurs autour des SGBD mais vu que je ne suis pas expert de domaine je souhaite le valider avec vous.
Dans l'un des nouveaux projets que nous allons entamé le DBA de mon client exigence que le code soit sous forme des routines SQL
- pas de lectures et d'écriture directement sur les tables (uniquement des views)
- toutes les requêtes sont sous forme de procédures stockés (select, update insert et delete)
- posé toutes contraintes du métiers au niveau de la base de données (contrainte check)

Mais je trouve que peut être ca va compliqué un peu les développements sur tout au niveau du versionning de l'application et du déploiement (surtout que nos développeurs ont l'habitude de tout gérer dans le code de l'application même pour l'évolution de la base ils utilisent Entity Framework Code First)

Que pensez vous ?

Merci
A+

---

En pratique c'est beaucoup plus rapide en développement que n'importe quelle autre approche, ORM compris ! mais pour cela il faut être SOLIDEMENT formé !
C'est ce que l'on appelle le développement épais...
À priori je dirais que votre client à lut mes articles... !

Lisez l'article que j'ai écris (il y a longtemps) sur le sujet :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf

Il n'y a rien de plus facile à comptabiliser que des procédures. En effet, aucune requête aussi simple soit elle ne donne exactement les mêmes résultats sur tous les SGBDR !

A +

Citation:

---

Envoyé par SQLpro

À priori je dirais que votre client à lut mes articles... !

Lisez l'article que j'ai écris (il y a longtemps) sur le sujet :
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
A +

---

C'est le même article que mon client m'a fourni. 😀😀
J'ai déjà parlé avec un autre ami qui a des connaissances assez solide en Sql et en .Net, il déjà commencé à développer son premier module de son nouveau ERP en utilisant cette technique.
il faut pensé a convaincre notre chef d'unité de développement de laisser tombé les ORM au moin au niveau de ce projet 😑😑

Citation:

---

Envoyé par erpWorld

J'ai déjà parlé avec un autre ami qui a des connaissances assez solide en Sql et en .Net, il déjà commencé à développer son premier module de son nouveau ERP en utilisant cette technique.

---

En partant aussi des conseils de SQLpro (de son blog) dans la phase de modélisation (héritage, entité de références..)