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

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?

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.

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!

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.

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.

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.

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.

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

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?

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.