Code d'abord vs base de données d'abord
Lorsque je conçois et crée le logiciel sur lequel je travaille, je conçois et crée généralement les tables SQL principales en premier, puis je passe à la programmation réelle. Le projet sur lequel je travaille actuellement me laisse perplexe. Cela est probablement dû à un manque de bonnes exigences solides, mais malheureusement je ne peux pas faire grand-chose à ce sujet cette fois. C'est une sorte de situation "allez-y, allez-y" ... mais je m'éloigne du sujet.
Je pense à renverser mon flux de travail sur sa tête et à créer d'abord les classes d'interface utilisateur et de modèle de données dans l'espoir que cela me permettra de comprendre à quoi ressemblera mon schéma de base de données. Est-ce une bonne idée? Je suis nerveux de me retrouver avec une interface utilisateur et toujours aucune idée de la façon de structurer la base de données.
Si quelqu'un est curieux, j'utilise SQL Server comme backend et MS Access comme application frontale. (L'accès n'est pas mon choix non plus ... alors s'il vous plaît, ne le détestez pas trop.)
Qu'est-ce qui est arrivé en premier, le processus ou les données utilisées par ce processus? Je sais que c'est une sorte de "poulet ou l'œuf", mais dans le cas des logiciels, je crois que c'est le processus.
Par exemple, vous pouvez créer votre modèle de données de manière incrémentielle en implémentant un seul cas d'utilisation à la fois avec juste une persistance en mémoire (ou quelque chose d'aussi facile à implémenter). Lorsque vous sentez que vous avez implémenté suffisamment de cas d'utilisation pour décrire les entités de base, vous pouvez remplacer la persistance en mémoire par une véritable base de données, puis continuer d'affiner le schéma au fur et à mesure, un cas d'utilisation à la fois.
Cela supprime le focus de la base de données et le déplace au cœur du problème: les règles métier. Si vous commencez par mettre en œuvre les règles métier, vous finirez par trouver (par un processus très similaire à Natural Selection, soit dit en passant) quelles données sont vraiment nécessaires à l'entreprise. Si vous commencez par modéliser la base de données, sans savoir si ces données sont vraiment nécessaires (ou dans ce format, ou à ce niveau de normalisation, etc.), vous finirez par faire beaucoup d'ajustements tardifs dans le schéma (qui peut nécessiter de lourdes procédures de migration, si l'entreprise est déjà en cours d'exécution avec lui), ou vous devrez implémenter des "solutions" dans les règles métier pour compenser le modèle de données désaccordé.
TL; DR: La base de données dépend de l'entreprise - elle est définie par eux. Vous n'aurez pas besoin des données à moins d'avoir un processus qui fonctionne avec elles (un rapport est également un processus). Implémentez d'abord le processus et vous trouverez les données dont il a besoin. Modélisez d'abord les données et vous pourrez peut-être simplement compter le nombre d'hypothèses erronées lorsque vous les avez modélisées pour la première fois.
Un peu hors du sujet mais très important: le flux de travail que je décris est souvent utilisé avec des pratiques très importantes telles que "La chose la plus simple qui pourrait éventuellement fonctionner", le développement piloté par les tests et l'accent mis sur le découplage de votre architecture des détails qui mettez-vous sur votre chemin (indice: base de données). À propos du dernier, cet exposé résume assez bien l'idée.
Une analyse des causes profondes suggère que ce problème n'est pas un problème de méthode, mais est le manque de spécification. Sans celui-ci, peu importe ce que vous écrivez en premier - vous allez tout de même le jeter.
Faites-vous plaisir et faites une analyse de base des systèmes - identifiez des utilisateurs à différents niveaux, créez un questionnaire rapide et sale, puis éteignez votre machine, prenez du café et des biscuits/beignets (ou tout ce qui graisse les roues), puis faites une promenade jusqu'à leurs bureaux, demandez-leur ce qu'ils font et ce qu'ils doivent savoir/enregistrer pour faire leur travail même si cela semble évident - demandez toujours. Ne vous inquiétez pas de leur importance, s'ils sont trop occupés, prenez des dispositions pour revenir une autre fois ou laissez-les.
Une fois que vous avez cela, vous devriez pouvoir commencer à construire tout ce que vous pensez qui vous donnera les meilleurs résultats et attendre que le reste des spécifications arrive.
Mon expérience est la suivante:
- Dans la plupart des projets sur lesquels j'ai travaillé, nous avons d'abord conçu la base de données.
- Souvent, les données existent déjà dans des feuilles de calcul, des bases de données héritées, du papier, etc. Ces données vous donneront des conseils sur les tables dont vous avez besoin pour les conserver.
- Souvent, un processus est déjà utilisé, mais manuellement ou en utilisant plusieurs outils disparates qui ne sont pas automatisés, n'interagissent pas et/ou ne sont pas conformes aux normes.
- Une fois que vous avez un modèle de base de données semi-mature, vous pouvez commencer à concevoir des prototypes de formulaires, de fenêtres, etc., qui lisent et écrivent dans cette base de données.
- Au fur et à mesure que vous continuez, certains changements seront nécessaires pour tenir compte des choses non envisagées au départ.
N'oubliez pas non plus:
- Ce n'est plus un monde avec une seule application <-> une seule base de données. Votre application devra peut-être lire ou écrire des données à partir de plusieurs bases de données ou votre solution comprendra plus d'une application utilisant la même base de données.
Conclusion: je vous recommande de concevoir la base de données en premier.
J'allais dire Database First car j'ai beaucoup d'expérience avec les grands projets et vous avez vraiment besoin d'un modèle de données solide si vous avez de nombreux développeurs travaillant en parallèle.
Mais ensuite, j'y ai réfléchi un peu plus et j'ai réalisé que ce que nous faisions vraiment sur les grands projets les plus réussis était "les exigences d'abord".
Un bon ensemble d'exigences commerciales bien spécifiées conduit à un bon ensemble d'exigences fonctionnelles. Si vous avez un bon ensemble d'exigences fonctionnelles, le modèle de données et les spécifications du module se mettent en place sans trop d'effort.
Étant donné que cela semble si fluide/non spécifié, je ferais d'abord l'interface graphique frontale - cela ressemble à ce dont vous avez besoin pour obtenir des réponses, du soutien, du temps et des commentaires des parties prenantes, non? Ils ne se soucient pas de vos brillantes tables normalisées et des contraintes de clés étrangères et des suppressions en cascade. Mais une interface graphique sympa avec beaucoup de couleurs brillantes - eh bien, c'est top!
Pour la "base de données" initiale du backend, utilisez quelque chose d'extrêmement simple, peut-être juste des clés/valeurs stockées dans un fichier. Je ne connais pas MS Access, donc je ne sais pas quel serait le backend "le plus léger". (un tableur?) Tout ce qui est rapide et sale, prévoyez de le jeter.
Si vous le pouvez, utilisez un look and feel drôle dans l'interface graphique pour indiquer clairement qu'il s'agit d'un prototype. Si tout le reste échoue, utilisez des fiches.
Maintenant, peut-être que vos parties prenantes sont des experts DB - cela a été le cas avec moi parfois! - dans ce cas, faites quelques designs DB.