+ Répondre à la discussion
Affichage des résultats 1 à 12 sur 12
  1. #1
    Invité de passage
    Inscrit en
    septembre 2004
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 2
    Points : 0
    Points
    0

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

    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 ?

  2. #2
    Membre Expert

    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 226
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 226
    Points : 2 272
    Points
    2 272

    Par défaut

    Citation 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 ...

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 767
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 767
    Points : 30 501
    Points
    30 501

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  4. #4
    Invité de passage
    Inscrit en
    septembre 2004
    Messages
    2
    Détails du profil
    Informations forums :
    Inscription : septembre 2004
    Messages : 2
    Points : 0
    Points
    0

    Par défaut

    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.

  5. #5
    Membre chevronné

    Inscrit en
    mai 2005
    Messages
    414
    Détails du profil
    Informations forums :
    Inscription : mai 2005
    Messages : 414
    Points : 646
    Points
    646

    Par défaut

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

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 767
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 767
    Points : 30 501
    Points
    30 501

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  7. #7
    Membre chevronné

    Inscrit en
    mai 2005
    Messages
    414
    Détails du profil
    Informations forums :
    Inscription : mai 2005
    Messages : 414
    Points : 646
    Points
    646

    Par défaut

    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.

  8. #8
    Expert Confirmé Sénior
    Avatar de orafrance
    Inscrit en
    janvier 2004
    Messages
    15 966
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : janvier 2004
    Messages : 15 966
    Points : 18 742
    Points
    18 742

    Par défaut

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

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 767
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 767
    Points : 30 501
    Points
    30 501

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  10. #10
    Rédacteur en Chef
    Avatar de Marc Lussac
    Homme Profil pro
    Responsable marketing opérationnel
    Inscrit en
    mars 2002
    Messages
    27 901
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Responsable marketing opérationnel
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mars 2002
    Messages : 27 901
    Points : 45 809
    Points
    45 809

    Par défaut

    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).
    Ne pas me contacter pour le forum et je ne répondrai à aucune question technique. Pour contacter les différents services du club (publications, partenariats, publicité, ...) : Contacts

  11. #11
    Membre Expert
    Avatar de Alexandre T
    Profil pro
    Inscrit en
    mai 2002
    Messages
    1 025
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : mai 2002
    Messages : 1 025
    Points : 1 505
    Points
    1 505

    Par défaut

    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)...
    Alexandre T.

    PHP5/MySQL5 Codes prêts à l'emploi
    30 projets avec codes sources complets pour créer diaporamas photos, chat, arbre généalogique, statistiques de visites, création de graphiques, moteur de recherche, Sudoku etc...

    Mes articles

  12. #12
    Expert Confirmé Sénior
    Avatar de orafrance
    Inscrit en
    janvier 2004
    Messages
    15 966
    Détails du profil
    Informations personnelles :
    Âge : 37

    Informations forums :
    Inscription : janvier 2004
    Messages : 15 966
    Points : 18 742
    Points
    18 742

    Par défaut

    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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •