"Best practices" pour la gestion du code source de création des bases de données ?

[bincedecrabe]

Dans toutes les équipes de dev que j'ai vues, les environnements applicatifs des développeurs étaient indépendants : Chacun a son compilateur, sa machine virtuelle (Java ou autre, ce n'est pas le sujet), son serveur d'application.
Les développeurs piochent leur code dans un gestionnaire de source (CVS, Subversion), le modifie, le teste, puis le redéposent et régulièrement, on voie ce que cela donne sur un poste d'intégration.

Tout cela fonctionne très bien. Ce qui m'intrigue, c'est que cette méthode de développement bien huilée pour le code de type applicatif n'est pas le même pour les modifications apportées dans les bases de données. En tout cas pas dans les équipes ou j'ai travaillé.

Contrairement aux environnements applicatifs indépendants pour chacun des postes, les bases de données sont communes à tous les développeurs.
...Et tout le monde passe des scripts de son côté, avec des règles... pas toujours respectées.
De plus, contrairement à l'applicatif, on ne peut pas recréer une base de données dans son intégralité lorsqu'on est en maintenance applicative ou corrective. Le client comprendrait mal que toutes ses données soient perdues.

Cela m'a déjà posé de sérieux problèmes lors du packaging du code source pour une livraison sur un environnement de recette. Les modifs réalisées sur la base de données de développements étaient mal tracés.

Or, je considère mon code comme un tout, c'est le code source applicatif ET le schéma de la base de données qui va avec (et n'importe quel autres composants d'ailleurs).

Ma question est donc la suivante :
Comment gérer vous les modifications des bases de données et comment livrez vous ces modifications sur d'autres environnemnets ?

[Luc Orient]

Envoyé par bincedecrabe

...
Contrairement aux environnements applicatifs indépendants pour chacun des postes, les bases de données sont communes à tous les développeurs.
...Et tout le monde passe des scripts de son côté, avec des règles... pas toujours respectées.

N'oublions pas qu'un SGBD relationnel possède ses propres méta-données (on parle parfois de catalogue) et beaucoup d'outils s'appuient sur ce concept pour gérer les évolutions ...

De plus, contrairement à l'applicatif, on ne peut pas recréer une base de données dans son intégralité lorsqu'on est en maintenance applicative ou corrective. Le client comprendrait mal que toutes ses données soient perdues.
...

ça fait partie du travail du DBA de gérer cette problématique d'évolution des données par rapport à l'évolution de la structure et là aussi de nombreux outils existent pour l'aider ...

Cela m'a déjà posé de sérieux problèmes lors du packaging du code source pour une livraison sur un environnement de recette. Les modifs réalisées sur la base de données de développements étaient mal tracés.

N'oublions pas les solutions organisationnelles. La fonction de DBA, même si elle est parfois remise en cause, implique bien une certaine centralisation de l'évolution de la structure de la base de données ....

Or, je considère mon code comme un tout, c'est le code source applicatif ET le schéma de la base de données qui va avec (et n'importe quel autres composants d'ailleurs).

Il existe plusieurs "bonnes pratiques" pour avoir une relative indépendance des données et des programmes, par exemple l'utilisation des vues offertes par le SGBD ... D'autres techniques existent ...

[SQLpro]

1) utiliser un outil de modélisation qui gère les différentes évolutions de la base. Par exemple Power AMC (ex Amc Designor) de Sybase.
Il gènère automatiquement les scripts SQL différentiels entre une version archivée d'un modèle et la dernière MAJ.

2) conserver TOUS les scripts dans un répertoire de sauvegarde

3) ajouter à votre application :
- une table de versionning de schéma qui permettra de savoir chez le client sur quelle version de la base tourne le client
- un module (outil .exe par exemple) capable d'ingérer les scripts différentiels et qui vérifie qu'à chaque release de l'applicatif derière, le nouveau code soit en cohésion avec la version de la base.

A +

[bincedecrabe]

Merci Luc pour ta réponse... mais tu ne m'aides pas vraiment. En gros, c'est le travail du DBA. J'essaie justement de comprendre commment bien faire ce travail : Je n'ai pas de DBA à plein temps dans ma boîte.
Et je ne veux pas le déranger toutes les 30 secondes à chaque fois que j'ai besoin de modifier mon schéma.

Merci à SQL Pro pour tes pistes très intéressantes.
Pourquoi pas Power AMC. Ca a l'air de correspondre précisement à ce dont j'ai besoin : Générer les scripts différentiels entre deux versions de schémas.

Bon, j'ai peut-être trop une approche développeur de la chose : mais j'aimerais trouver une méthode sans Power AMC. J'ai déjà beaucoup d'outil.

[gregory.broissard]

c'est clair!

Je ne pense que ce soit le travail d'un DBA de gérer les environnements de developpement!

essayez d'imaginer le travail de titans si dans la société, il y a 100 à 150 projets de developpement en parallele!!!!! La priorité des DBAs, c'est la production et pas recréer des environnements de dev toutes les heures.
C'est bien le développeur qui doit être responsable de sa structure de "base" applicative.


Pour ce qui est de recréer des bases de données. Il est normal que les developpeurs puissent recréer des bases en environnement de dev, par contre il est logique, qu'ils ne puissent pas recréer des bases en environnement de qualité, recette, préproduction et production. Ce sont des environnements qui doivent être à l'image de la prod et qui sont utilisées par des utilisateurs (AMOA, MOA, utilisateurs,etc...) donc c'est normal que le client ne souhaite pas de suppression brutale sur ces environnements! sur ces environnements, DBA et exploitation interviennent.

Effectivement, il existe des outils (comme le fait remarquer SQLPro) mais ca ne solutionnera pas tous tes problèmes je pense. comme tu le dis "certains ne respectent pas les règles", et bien ils doivent apprendre à les respecter. Question d'éducation...

[SQLpro]

Grégrory je ne suis pas d'accord du tout d'accord avec toi.

C'est au DBA que l'on va demander des performances sur les bases de données exploitées. Or 50 à 80 % des problèmes de performances viennent directement d'un mauvais modèle de données. C'est ce que je constate à longueur d'audits et que je montre dans le cours de formations d'optimisation sur MS SQL Server que j'ai monté pour orsys (http://www.orsys.fr/pdfCours/SQO.pdf).

C'est donc bien au DBA de qualifier la structure de données, l'architecture de la base, le choix des types de données, les collations...
C'est à lui que reviendra l'éventuelle dénormalisation si le besoin de performances se fait sentir.
C'est donc à lui de donner les bonnes préconisations au démarrage d'un projet et de valider tous les modèles.

D'ou l'importance extrême d'un outil de modélisation conceptuel + physique afin de centraliser toutes les modifs de la base.

Mais sans doute à 46 balais, suis-je un vieux con "has been", drogué au SQL ! ;-)

A +

[gregory.broissard]

Je suis d'accord sur ce point. C'est DBA qui qualifie et valide les modèles lors du démarrage du projet en réalisation et qui donne des précos en cours de dév.

Par contre, ce n'est pas à lui d'installer des bases, remettre à 0, créer et recréer des bases sur des environnements de dev.

[orafrance]

ha... tiens donc... les développeurs ne sont pas sensés avoir les formations requises pour pouvoir assumer ces tâches pourtant

[SQLpro]

Fred_D :

ha... tiens donc... les développeurs ne sont pas sensés avoir les formations requises pour pouvoir assumer ces tâches pourtant

Ils devraient avoir un vernis minimum sur les bases de données relationnelles, le langage SQL et la modélisation de données. Mais nous sommes en France, pays ou le tissus scolaire et universitaire est tenu par des fonctionnaires qui sont loin de se remettre en question et dans lequel la formation professionnelle se réduit à peau de chagrin du fait des politiques et des entreprises.

Sur le plan cursus scolaire, quand vous voyez que la plupart des cours universitaires et de grandes écoles se sont arrêté aux jointures dans la clause WHERE et non jamais été ré écrit, alors que la norme impose depuis 1992 le JOIN... ... ya pas de quoi être fier de l'enseignement français :
Quelques petits exemple :
1) Supelec, cours de Yolaine Bourda (cité dans nos référence) :
http://wwwsi.supelec.fr/~yb/poly_bd
2) Joel Quinqueton, Monpeliier II et III
http://www.lirmm.fr/~jq/Cours/MASS/L...s/algRelBd.pdf
3) Vitold Litvin, Dauphine
http://ceria.dauphine.fr/cours98/CoursBD/SQL2-97.ppt

...

Ajoutons a cela des formations professionnelles d'éditeurs comme Microsoft Ou Oracle ou 40% du cours est plus orienté marketing que connaissance techniques...

Une des raisons pour lesquelles je ne suit pas le circuit de cours officiel MS pour ce qui est de SQL Server, mais que je fabrique de toute pièces des cours pour certaines boites de formation, dans laquelle on aborde le véritable sujet et non pas une présentation de 3h sur comment envoyer un mail avec SQL server en passant par MAPI, outlook, exchange et Windows server !

En conclusion la formation SGBDR / SQL est assez nul sur le plan universitaire et professionnel, ce qui conduit à des développeurs ignorants.

Voire par exemple le niveau de certaines question posée dans le forum. Hier par exemple sur le forum MS, la question stupide était :

"
Comment avoir une table qui enregistre des données mais pour
lesquelles les lignes ne seront jamais supprimées, même après un ROLLBACK
"

A +

[Marc Lussac]

Je pense que la formation base de données doit faire partie de la formation des développeurs. Ca me paraitrait être un gros point faible de voir un cursus de formation de développeurs sans matière SGBD. D'autre part comme écrit ci dessus la formation peu ne pas etre assez poussée dans ce domaine.

Ceci dit même avec une matière SGBD dans un cursus, tous le monde n'est pas sensible de la même manière à l'interet et à l'importance de cette matière, et à la sortie d'une école on peu avoir un grand pourcentage d'individus totalement inapte à faire un bon modèle des données. C'est la que la notion d'expérience et de talent apparait (ou pas).

[Alexandre T]

Je réagis sur les propos de SQLPRO et de Marc par mes témoignages...

Je suis diplomé de Miage en 2002... Les jointures se font encore en "WHERE" et non en "JOIN"... alors que c'est une formation dite "gestion" orienté base de données... Chapeau bas...

Notre dernier stagiaire (dernière année d'IUT) ne connaitrait pas le SQL si il ne se formait pas à côté. Pas au programme (ou du moins survol : 3 heures de cours en somme)...

[orafrance]

désolé, j'avais mal lu la dernière phrase de Gregory et pensait qu'il disait que le dév devait aussi administrer les bases de dév

Fred, tu as complétement raison et je pousserai même la formation à l'administration courantes des bases : création d'espace de stockage, paramètres de création des tables et indexes, fonctionnement des indexes, plan d'exécution des requêtes, etc... un verni minimum pour éveiller l'intérêt des étudiants en plus de les sensibiliser aux problèmatiques de performance et stockage de données.

Finalement, je crains que trop de professeurs ont des expériences professionnelles obsolétes voir inexistente... c'est bien dommage puisque je n'ai pas eu le même sentiment pendant mes études concernant les professeurs de programmation ou de droit par exemple