Devez-vous concevoir la base de données avant que le code de l'application ne soit écrit?

57

Quel est le moyen le plus simple et le plus efficace de concevoir une base de données? De mon point de vue, il existe plusieurs options pour la conception du magasin de données d'une application:

  1. Concevez au mieux la base de données avant de pouvoir écrire un code d’application . Cela vous donne l’avantage d’avoir une structure de données de base sur laquelle travailler. À mon avis, l’inconvénient est que vous aurez beaucoup de changements en tant que spécificités d’application qui affectent le changement de type de données (quoi / où / comment) tout au long du cycle de développement de l’application.
  2. Concevez la base de données au fur et à mesure que l'application se concrétise . Lorsque vous avez besoin d'objets de base de données lors de l'écriture de l'application, vous développez la base de données parallèlement (chronologiquement) à l'application. Les avantages seraient moins de changements à la structure de la base de données telle que je la vois. L'inconvénient serait la division du temps et des efforts de développement entre le code d'application et le développement de bases de données.

D'après votre expérience, quelle est selon vous la méthode la plus productive et la plus efficace?

Thomas Stringer
la source
Divide and Conquer avec SDLC
Premraj
1
Flywaydb.org pourrait vous intéresser. Il vous permet de contrôler la version de votre schéma de base de données.
Thorbjørn Ravn Andersen

Réponses:

41

En plus d'autres réponses ...

Capturer d'abord votre modèle conceptuel devrait définir la portée et les exigences. Vous pouvez en déduire vos modèles de données logiques et physiques.

Une fois que cela est principalement statique, vous avez une base de données stable sur laquelle construire votre application. Ceci est contraire à votre première option.

Votre deuxième point se terminera par une boule de boue désordonnée et intenable . Le modèle de données ne sera jamais réparé: si vous ne l'avez pas conçu à l'avance, vous n'aurez pas le temps de le réparer avant l'expédition. Vous serez trop occupé à pirater des choses ensemble.

Des modifications mineures du schéma, combinant ou divisant des tables, des relations changeantes, etc., auront lieu, mais dans des "îlots" localisés, votre conception modèle + de base ne sera pas modifiée.

gbn
la source
6
Et la stabilité est importante, car les noms de table et de vue, les noms de colonne, les noms de procédure stockée, etc. constituent l'interface publique de la base de données. (Et tôt ou tard, de nombreuses applications partageront cette interface.)
Mike Sherrill 'Cat Recall'
Je dirais que c'est une approche assez idéalisée, mon expérience étant que des changements radicaux se produisent de temps en temps, nous devons être agiles, nous adapter rapidement aux nouvelles exigences et continuer à refactoriser.
Zinking
@zinking: Je fais la chose agile en ce moment.
gbn
@gbn, désolé de poser la question ci-dessous ici. Je ne sais pas comment gérer le scénario. Veuillez regarder. stackoverflow.com/questions/46285924/… . Suggérez-moi la meilleure solution.
RGS
27

Vous aurez du mal à trouver un service informatique moderne qui n’exploite pas une variante de Agile. À titre de comparaison, les administrateurs de bases de données sont coincés dans l'âge des ténèbres, avec le type de pensée que la réponse de @ RobPaller contient encore un lieu commun.

La modification d’un schéma de base de données n’a jamais été aussi simple que de modifier le code. C’est pourquoi on a hésité à adopter une approche agile pour le développement et la maintenance de la base de données. Maintenant que nous disposons des outils et des techniques pour fonctionner de la même manière que les développeurs, nous le devrions certainement. Le simple fait de changer de schéma ne signifie pas que vous ne pouvez pas et que vous ne devriez pas.

Je ne préconise pas une approche aléatoire de la conception de bases de données (voir commentaires), mais simplement une approche plus proche de celle d'une équipe de développement agile. Si vous faites partie d'un projet agile, vous ne serez pas soumis à des exigences de travail susceptibles de se produire ( ou non ) à l'avenir. Par conséquent, concevez ce dont vous savez qu'il est nécessaire et non ce qu'il pourrait être.

Je suppose que cela met mon vote avec votre option 2 et je soupçonne que je pourrais me retrouver dans le froid sur celui-ci!

Mark Storey-Smith
la source
4
Agile et les bases de données vont de pair avec des mises en garde. Agile est limite pour les VLDB: le temps imparti pour valider et tester les modifications apportées à des milliards de tables de lignes entre les livrables est peut-être insuffisant. Et le "développement agile" n'est pas la même chose que les "changements en gros" en raison d'un manque de prévoyance
gbn
2
Ne pouvais pas être plus d'accord sur le manque de prévoyance, mais je ne pense pas que cela soit pertinent pour la question. Il ne s'agit pas de savoir si vous devez aborder la conception de manière aléatoire, mais bien si votre modèle de données doit évoluer au même rythme que l'application. Les problèmes VLDB justifient une modification que je vais ajouter.
Mark Storey-Smith
3
J'ai lu la question comme "une nouvelle application sans base de données pour le moment" plutôt que "une application existante nécessitant des modifications de la base de données"
gbn
De même, il me manque quelque part votre point :) Un à prendre pour discuter?
Mark Storey-Smith
4
+1 pour le sentiment général de votre réponse, mais "Modifier un schéma de base de données n'a jamais été aussi simple que modifier du code" dépend vraiment de la quantité de code que vous avez (et de son âge). OMI, l'inverse est plus généralement vrai
Jack Douglas
12

Votre modèle de données logique doit bien prendre en compte les besoins de votre application. La conception de votre base de données physique doit être basée sur le modèle de données logique, associé aux modifications nécessaires qui, en tant que DBA, sont nécessaires pour optimiser l'efficacité de votre SGBDR.

Si vous constatez que vous devez apporter de nombreuses modifications à la conception de la base de données sous-jacente tout au long du cycle de vie du développement logiciel de votre application, cela indique deux choses:

  1. Portée rampante - Vous autorisez l'introduction de nouvelles exigences à un moment inapproprié.
  2. Besoins métier insuffisants - Votre modélisateur de données (ou vos analystes système) n'a pas suffisamment traduit les besoins des analystes métier. Cela a abouti à un modèle de données incomplet ou incorrect pour répondre aux exigences de votre application.

Cela dit, une fois qu'une application a été mise en production, il n'est pas rare de devoir revenir en arrière et d'apporter des modifications itératives au modèle de données afin de prendre en charge l'évolution naturelle de l'application ou des processus métier sous-jacents.

J'espère que cela t'aides.

RobPaller
la source
7
Ajouter de nombreuses nouvelles exigences au cours d'un projet n'est pas "inapproprié". C'est quelque chose que vos méthodes de développement devraient soutenir et encourager. Www.agilemanifesto.org/principles.html
nvogel
1
Je connais bien certains principes du développement agile et je les ai mis en avant dans une capacité d'entreposage de données où cela a du sens pour l'entreprise. Merci pour votre commentaire.
RobPaller
11

J'ai eu le luxe de concevoir plusieurs bases de données de complexité moyenne, toutes utilisées dans les entreprises, avec différents frontaux, y compris Web, Access et C #.

D'habitude, je me suis assis et j'ai élaboré le schéma de base de données à l'avance. Cela a toujours eu le plus de sens pour moi. Cependant, il n'y a pas eu un seul cas où je n'ai pas fini par apporter des modifications, ajouter de nouveaux tableaux ou vivre avec des aspects qui me dérangeaient et qui étaient fondamentalement trop tardifs pour être corrigés.

Je ne pense pas que le remède consiste à écrire le code en premier. Et je ne pense pas que le problème soit "des exigences professionnelles insuffisantes" ou du moins, pas une qui aurait pu être entièrement résolue. Les utilisateurs ne savent pas ce dont ils ont besoin et je n'ai pas le pouvoir de leur faire réfléchir plus fort, d'être plus intelligent ou plus conscient ou de mieux répondre à mes questions. Ou ils se disputent et on me commande de faire quelque chose d'une certaine manière.

Les systèmes que je construis se trouvent généralement dans de nouveaux domaines dans lesquels personne ne s’est jamais intéressé. Je n'ai pas l'adhésion de l'organisation, des ressources ou des outils pour faire le genre de travail qu'une équipe de développement composée de professionnels de la conception de premier plan pourrait recevoir et qui serait payée en équipe dix fois plus que ce que je gagne pour intégrer des éléments. deux fois le temps.

Je suis BON dans ce que je fais. Mais il n'y en a qu'un seul qui le fait dans un environnement qui "ne fait pas de développement".

Cela dit, je découvre de mieux en mieux les règles métier. Et je vois une sorte de troisième option:

Avant de concevoir la base de données, et avant d’écrire du code, dessinez des écrans bruts montrant le fonctionnement de l’application. Ils doivent être dessinés à la main pour empêcher quiconque de faire des commentaires sur la police, la taille ou les dimensions - vous souhaitez uniquement fonctionner.

Avec des transparents et des bouts de papier, vous pouvez basculer entre deux objets: une personne pour l'ordinateur, deux utilisateurs non spécialistes du domaine (deux pour qu'ils parlent à voix haute) et une personne pour l'animation qui prend des notes et dessine sur les utilisateurs de leurs processus de pensée et de confusions. Les utilisateurs "cliquent", glissent et écrivent dans des cases, "l'ordinateur" met à jour l'écran et tout le monde peut expérimenter le design. Vous apprendrez des choses que vous n'auriez pas pu apprendre autrement jusqu'à un stade avancé du processus de développement.

Peut-être que je me contredis - c'est peut-être une meilleure découverte des exigences. Mais l’idée est de concevoir l’application d’abord, sans écrire de code. J'ai commencé à le faire à petite échelle et ça marche! Malgré les problèmes de mon environnement, cela m'aide à améliorer la conception de la base de données dès le début. J'apprends qu'une colonne doit être déplacée dans une nouvelle table parent car il existe plusieurs types. J'apprends que la liste de travail doit contenir des ordres permanents qui ne proviennent pas du système de commande intégré. J'apprends toutes sortes de choses!

À mon avis, c'est une victoire énorme.

ErikE
la source
+1 excellente réponse. Le développement facilité des exigences est un énorme plus dans un projet à plusieurs parties prenantes.
Zayne S Halsall
10

Dans la plupart des cas, je choisirais l'option 2: construire la base de données en parallèle avec les autres composants. Autant que possible, adoptez une approche itérative et fournissez une fonctionnalité complète au fur et à mesure que vous créez chaque élément.

Cela nécessite une certaine discipline du projet. Appliquez la normalisation de manière rigoureuse (Boyce-Codd / Fifth Normal Form) à chaque fois que vous modifiez la base de données afin de maintenir la qualité et de ne pas vous retrouver avec un modèle ad-hoc et incohérent. Soyez aussi agressif que possible avec les règles métier et les contraintes de base de données correspondantes. En cas de doute, il est préférable d'appliquer une contrainte tôt - vous pouvez toujours la supprimer plus tard. Soyez avisé de l'ordre dans lequel vous implémentez des composants architecturaux de manière à minimiser la dette technique. Ayez un bon ensemble de directives de conception de base de données auxquelles toute l'équipe de développement souscrit.

Bien entendu, tout cela doit aller de pair avec d’autres bonnes pratiques d’ingénierie de développement: intégration continue, automatisation de test et, d’une manière cruciale, du point de vue de la base de données, création de données de test. La création de données de test de données de taille réaliste doit être effectuée à chaque itération sans échec.

nvogel
la source
2
Ne pensez-vous pas qu'une réflexion préalable serait nécessaire pour définir un modèle conceptuel?
gbn
Certaines réflexions initiales peuvent être utiles, mais tenter de définir l’ensemble du modèle à l’avance est généralement contre-productif. Le modèle doit correspondre aux exigences de l'entreprise et aux produits livrables du projet (application incluse) à mesure qu'ils évoluent. Vous ne pouvez et ne devez pas vous attendre à ce que ces choses ne changent pas. En outre, la création du modèle entier à l’avance peut en réalité gêner les autres développements en raison de la nécessité de créer des interfaces factices pour prendre en charge les parties non encore utilisées du schéma.
Nvogel
Je soupçonne @dportas et je travaille dans des environnements similaires :)
Mark Storey-Smith Le
9

Dans le monde de l'architecture, l'expression "Form Follows Function" a été inventée et ultérieurement respectée lors de la construction de bâtiments de grande hauteur. La même chose devrait être appliquée à l'infrastructure de base de données et au développement d'applications.

Imaginez que vous écriviez une application et décidiez à la volée qu'il vous faut une table ici et une table ici. Lorsque votre application est terminée, un grand nombre de tables sont traitées comme des tableaux. En regardant toutes les tables côte à côte, il semblera qu'elles n'auront ni rimes ni raisons.

Malheureusement, certains magasins de développeurs vont chercher quelque chose comme memcached, le charger avec des données dans la RAM (le traitant ainsi comme un canal de données) et faire en sorte qu'une base de données, telle que MySQL ou PostgreSQL, se comporte simplement comme une unité de stockage de données.

L'incitation à utiliser une base de données devrait être de l'examiner correctement: en tant que SGBDR. Oui, un système de gestion de base de données relationnelle . Lorsque vous utilisez un SGBDR, votre objectif initial ne devrait pas être uniquement d'établir des tables pour le stockage, mais également pour la récupération. Les relations entre les tables doivent être modélisées d'après les données que vous souhaitez voir et leur présentation. Cela devrait être basé sur la cohésion et l'intégrité des données ainsi que sur les règles commerciales connues. Ces règles de gestion peuvent être codées dans votre application (Perl, Python, Ruby, Java, etc.) ou dans la base de données .

CONCLUSION

J'opterais certainement pour l'option 1. Une planification, une modélisation des données et une analyse continue des données sont indispensables. Pourtant, cela devrait minimiser les modifications de la base de données à long terme.

RolandoMySQLDBA
la source
1
@RolandoMySQLDBA, vous supposez qu'une conception de base de données générée lors du développement d'une application sera moins performante que celle construite auparavant? Pourquoi? Le contraire est souvent vrai.
nvogel
1
@dportas: Mon accent est mis sur l'option 1 en termes de minimisation des modifications dans la conception de bases de données. J'ai passé les deux tiers de ma programmation de carrière dans des magasins où des modèles de données et des infrastructures très complexes étaient transformés presque tous les mois. J'ai craqué pour de tels changements parce que les besoins et les objectifs de l'entreprise n'étaient pas gravés dans la pierre. Je suis assez vieille école en cela. Rien de mal à être un petit franc-tireur tant que la conception ne génère pas beaucoup de «dette technique» (oui, je vous ai répondu) au fil du temps.
RolandoMySQLDBA
2
+1 pour "utiliser un SGBDR en tant que base de données relationnelle, pas pour des tableaux", quelle que soit l'approche choisie
Jack Douglas
2
@dportas: Bien que cela soit vrai (les règles commerciales changent), une base de données bien conçue ne changera pas radicalement entre une itération (ou un sprint, ou autre) et une autre, car elle reflète toutes les structures de données pertinentes du processus de travail. Si cela se produit (changement radical), cela signifie un échec des activités de capture de règles métier.
Fabricio Araujo
3
@dportas: pas tous les changements de base de données, seulement ceux de RADICAL. Les modifications mineures font partie de la fabrication de logiciels. Toutefois, le fractionnement des données dans deux bases de données différentes en cours de travail est un échec pour la conception et la capture des règles commerciales. (Cela m'est effectivement arrivé.
Fabricio Araujo
9

Je pense que cela devrait être fait avant qu'il y ait un code réel pour l'application, mais pas avant la conception de l'application.

Mon flux de travail typique, si travailler seul est:

  1. Déterminer ce que l'application doit faire
  2. Regardez pour voir si l'une des tâches peut être décomposée pour les composants réutilisables
  3. Déterminez comment chaque tâche doit interagir avec le stockage de données - quel type de questions poseront-elles des données, à quelle fréquence vont-elles écrire, etc.
  4. Concevez la base de données de manière à ce qu’elle puisse répondre à toutes les questions que nous devons lui poser et fonctionne bien pour les tâches les plus fréquentes.
  5. Écrivez l'application.

Comme je travaille souvent en équipe et que nous sommes dispersés géographiquement (et sur plusieurs fuseaux horaires), nous avons généralement une première réunion de lancement:

  1. Déterminez ce que l'application doit faire.
  2. Déterminer les points forts pour diviser l’application en composants autonomes
  3. Déterminez comment chaque composant devra interagir avec les autres.
  4. Convenez d'une API pour chacune des interactions.

Ensuite, nous retournons à la maison, écrivons notre pièce et si un composant a besoin de son propre stockage local, tant que le responsable de cette pièce garde la cohérence de l'API de son module. Le stockage de données principal est traité comme un module avec sa propre API et les utilisateurs sont censés y écrire. (Dans les cas où la vitesse de la base de données est critique, l'API correspond aux définitions de table et, si des modifications sont apportées, nous utilisons des vues ou un autre mécanisme pour présenter l'ancienne version jusqu'à ce que tous les modules puissent être mis à jour.)

Joe
la source
1
Le cas de l'option 2 est qu'avec une méthodologie agile, vous ne connaissez pas 1, 2 ou 3 autres que celles prévues pour le prochain sprint. Le changement est inévitable, dans la portée, les exigences et les attentes.
Mark Storey-Smith
8

Je pense à la règle suivante: "vous ne pouvez obtenir d’une base de données que les informations que vous avez des données à générer". Donc, je conçois d’abord la base de données, puis le code.

Pourquoi? Peu importe la métodologie, le langage ou les outils que j'utilise, si toutes les données pertinentes sont bien conçues et stockées dans la base de données, je peux les récupérer. Que ce soit en C # / Delphi / FORTRAN / COBOL / Assembly / VBA ou Crystal Reports; OO conçu ou événement / données / quel que soit conduit; agile ou cascade. Si les données sont là, je peux les récupérer si les outils que j'utilise peuvent se connecter à la base de données. Je peux créer les rapports sur les ventes si je peux SÉLECTIONNER les commandes pour les revenus du trimestre, même si je dois l'écrire octet par octet dans Assembly.

Si les données pertinentes ne sont pas présentes ou même si elles sont présentes mais (non) structurées de manière à ne pas récupérer les informations dont j'ai besoin - comment les coder?

Fabricio Araujo
la source
7

Comme d'habitude, ça dépend;)

Par exemple, supposons que nous ayons un prototype fonctionnel de petite taille développé en Python et utilisant des fichiers à plat, et que les utilisateurs soient satisfaits des fonctionnalités du prototype. Il suffit donc de le produire, en utilisant le SGBDR comme support. . Lorsque c'est le cas, il est raisonnable de s'attendre à le faire correctement du premier coup - le problème est petit et bien défini. Dans de tels cas, il est possible de concevoir à l’avance.

D'autre part, lorsque nous découvrons les exigences dans un environnement Agile, nous avons besoin de quelques itérations pour mieux les comprendre. Dans de telles situations, la base de données évolue avec le reste de l'application. C'est ce que nous faisons habituellement. Étant donné que nous pouvons refactoriser les tables OLTP en direct sans temps d’immobilisation et avec un risque faible, nous sommes à l’aise avec la possibilité de refactoriser les bases de données.

AK
la source