Code d'abord contre 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 d'abord les tables SQL principales, puis je passe à la programmation proprement dite. Le projet sur lequel je travaille actuellement me laisse perplexe. Ceci est probablement dû à un manque d'exigences solides et solides, mais je ne peux malheureusement rien faire à ce sujet cette fois-ci. C'est une situation du genre "il suffit d'y aller", mais je m'éloigne du sujet.

Je pense renverser mon flux de travail et créer d'abord les classes d'interface utilisateur et de modèle de données dans l'espoir que cette opération m'indique clairement à quoi ressemblera mon schéma de base de données. Est-ce une bonne idée? Je suis nerveux car je vais 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 serveur principal et MS Access comme application frontale. (L'accès n'est pas mon choix non plus ... alors, je vous en prie, ne détestez pas trop.)

Qu'est-ce qui est apparu en premier, le processus ou les données utilisées par ce processus? Je sais que c’est un peu la question de la "poule ou de l’œuf", mais dans le cas des logiciels, je crois que c’est le processus.

Par exemple, vous pouvez construire 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 simple à implémenter). Lorsque vous estimez avoir 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 base de données réelle, puis continuer à affiner le schéma à mesure que vous avancez.

Cela détourne l'attention de la base de données et la déplace au cœur du problème: les règles métier. Si vous commencez par implémenter les règles de gestion, vous finirez par trouver (selon un processus très similaire à Natural Selection) les données dont l'entreprise a réellement besoin. Si vous commencez par modéliser la base de données, sans savoir si ces données sont vraiment nécessaires (ni dans ce format, ni à ce niveau de normalisation, etc.), vous finirez par effectuer de nombreux ajustements tardifs. le schéma (qui peut nécessiter de lourdes procédures de migration, si l'entreprise l'exécute déjà), ou vous devrez implémenter des "solutions de rechange" dans les règles de gestion 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 elle. Vous n’avez pas besoin des données sauf si vous avez un processus qui fonctionne avec elles (un rapport est aussi un processus). Commencez par mettre en œuvre le processus et vous découvrirez 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 lors de la modélisation.

Un peu en dehors 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 puisse fonctionner", un développement piloté par des tests et une focalisation sur le découplage de votre architecture des détails se mettre en travers de votre chemin (indice: base de données). À propos du dernier, cette discussion résume assez bien l’idée.

Une analyse de la cause première suggère que ce problème n’est pas un problème de méthode, mais plutôt un manque de spécification. Sans l'un, ce que vous écrivez d'abord n'a pas vraiment d'importance - vous allez le jeter de toute façon.

Faites-vous une faveur et faites une analyse basique des systèmes - identifiez des utilisateurs à différents niveaux, créez un questionnaire rapide et sale, éteignez votre machine, prenez un café et des biscuits / beignets (ou tout ce qui lubrifie les roues), puis promenez-vous 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 les dispositions nécessaires pour revenir ou leur laisser la tâche.

Une fois que vous avez cela, vous devriez pouvoir commencer à construire ce que vous pensez qui vous donnera les meilleurs résultats et attendre que le reste de la spécification entre en jeu.

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.
• Il arrive souvent que des données existent déjà dans des feuilles de calcul, des bases de données traditionnelles, du papier, etc. Ces données vous donneront des indications sur les tables dont vous avez besoin pour les conserver.
• Souvent, un processus est déjà utilisé, mais manuellement ou à l'aide de plusieurs outils disparates qui ne sont pas automatisés, qui ne fonctionnent pas entre eux 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 formulaires prototypes, des 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 prendre en compte des éléments non envisagés au début.

Rappelez-vous aussi:

• Ce n'est plus un monde avec une seule application <-> une base de données. Peut-être que votre application devra lire ou écrire des données provenant de plusieurs bases de données ou que votre solution comportera plusieurs applications utilisant la même base de données.

Conclusion: je vous recommande de concevoir d'abord la base de données.

J'allais dire Base de données d'abord, car j'ai beaucoup d'expérience dans les grands projets et vous avez vraiment besoin d'un modèle de données solide si plusieurs développeurs travaillent en parallèle.

Mais ensuite, j'ai réfléchi un peu plus et j'ai réalisé que ce que nous faisions réellement sur les grands projets les plus réussis était "les exigences d'abord".

Un bon ensemble d'exigences métier bien spécifié 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 de module s’imposent sans effort.

Étant donné que cela semble si fluide / non spécifié, je commencerais par 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, n'est-ce pas? Ils se moquent de vos brillantes tables normalisées et de vos contraintes de clés étrangères et de vos suppressions en cascade. Mais une interface graphique cool avec beaucoup de couleurs brillantes - eh bien, c'est top!

Pour la "base de données" initiale, utilisez quelque chose d'extrêmement simple, peut-être juste des clés / valeurs stockées dans un fichier. Je ne suis pas familier avec MS Access, donc je ne sais pas ce que serait le backend "le plus léger". (une table écalée?) Quoi que ce soit qui soit rapide et sale, envisagez de le jeter.

Si vous le pouvez, utilisez une interface amusante dans l'interface graphique pour indiquer clairement qu'il s'agit d'un prototype. Si tout échoue, utilisez des fiches.

Maintenant, peut-être que vos intervenants sont des experts de la base de données - cela a parfois été le cas avec moi! - Dans ce cas, réalisez certaines conceptions de base de données.

Comme les exigences ne sont pas claires, on peut commencer avec un modèle de données très rudimentaire avec les éléments clés dont vous saurez avoir besoin, peut-être juste des tables de base et des clés en main pour commencer. Le reste des données est sérialisé en binaire ou en XML et stocke le BLOB dans la base de données pour commencer. Cela devrait permettre de développer l'interface utilisateur et la couche métier (niveau intermédiaire) sans modèle entièrement relationnel, mais vous disposerez toujours de la persistance pour enregistrer et récupérer des recherches de clés simples, selon vos besoins.

Par exemple, vous avez peut-être une personne, alors vous avez une clé d'identification de personne. Le reste des attributs n'étant pas connu, commencez simplement par une table de personnes avec un identifiant de personne PK et une autre colonne qui stockera le blob, toutes les données de la personne.

Une fois les exigences consolidées, prenez vos blobs, extrayez toutes les tables et colonnes nécessaires et rendez le modèle relationnel. Ensuite, il suffit de changer la persistance d'un BLOB vers le relationnel dans la couche d'accès aux données. Mais tout le reste, l'interface utilisateur des règles commerciales, etc. fonctionnera toujours. Notez que cela ajoute un peu de temps au projet mais permet une flexibilité complète pour ajouter et supprimer des éléments si nécessaire sans modifier le modèle relationnel jusqu'à ce que les choses deviennent plus fermes.

La recherche peut être retardée car vous ne pouvez pas interroger un BLOB. Par conséquent, dès que le modèle se stabilise, commencez à stocker vos données à rechercher dans des colonnes relationnelles.

Fondamentalement, vous commencez avec un modèle tabulaire et passez à un modèle relationnel au fur et à mesure de l'avancement du projet.

Vous pouvez également préciser les exigences avant le début des travaux afin de pouvoir développer un modèle relationnel.

En général, je pense que le code vient après les données car il va manipuler les données.

Si les exigences ne sont pas claires, vous pouvez créer un modèle de données de votre interprétation des exigences. Le mieux est peut-être de noter certaines exigences et de les envoyer à votre employeur, ils auront alors quelque chose à tirer. Ou créez d'abord une interface graphique, cela dépend du type d'employeur qui fonctionne le mieux :)