Lorsque vous écrivez un article de blog sur la modélisation de base de données, vous devez être prêt à ce que votre modèle abstrait ne réponde pas aux besoins de la plupart des lecteurs. La raison est simple. Les modèles de base de données réels sont généralement créés en étroite relation avec des exigences commerciales et de développement spécifiques, contrairement aux modèles de blog.
Au cours des dernières semaines, j'ai écrit des articles de blog sur la création de modèles de base de données. Les sujets allaient d'une approche générale de la modélisation de base de données via un simple forum en ligne à un modèle pour une enquête en ligne plus complexe.
Pour chaque modèle de base de données que je crée, j'essaie de comprendre clairement le domaine de l'entreprise et d'élaborer dans mon esprit la vue d'ensemble du modèle.
Le défi du développement de bases de données abstraites
Normalement, en tant qu'architecte de solution , je prends des exigences commerciales spécifiques et je les convertis en détails techniques de ce qui doit être créé du côté technique :traduire du langage métier au langage technique - concevoir les algorithmes à un niveau élevé et modéliser les exigences de données pour les algorithmes.
Malheureusement, je ne peux pas bloguer sur les modèles de bases de données du monde réel que je crée au travail. D'une part, ils sont très spécifiques au domaine des affaires et d'autre part, je suis limité par des accords de confidentialité. Pour le blog, je crée un pur abstrait concept sans exigences commerciales spécifiques, à l'exception de celles que j'imagine exister dans le domaine des affaires. Maintenant, c'est bien; J'ai une assez bonne imagination et je signale fréquemment que vos exigences peuvent être différentes lorsque je décris les choix que je fais. Mais ce processus de blog m'a fait réfléchir à quel point ce processus est différent de la création de modèles dans un projet réel.
Le processus de développement réel
Dans une situation réelle, je travaillerais en étroite collaboration avec l'équipe de développement après avoir créé la solution de haut niveau et la conception technique dans un environnement interactif manière à ce que le modèle corresponde aux besoins de développement.
Les développeurs peuvent se plaindre que le modèle de données est trop normalisé pour prendre en charge des performances élevées, ou ils peuvent demander une normalisation supplémentaire dans certains domaines. Si des clés alternatives manquaient, les développeurs se plaignaient assez rapidement et nous le remarquions également lors des tests de performances de la base de données.
Nous examinerions quelles devraient être les longueurs exactes des champs en fonction de la longueur maximale des données à stocker et des conceptions d'écrans pour la saisie et l'affichage des données. Bien sûr, les longueurs exactes des champs dans un modèle de base de données conceptuel ne sont pas importantes.
Nous travaillerons sur des exemples de données qui seront stockées dans les tables et comment elles seront utilisées par l'application, et créerons des scripts pour pré-remplir les tables pour les tests unitaires de l'application. De cette façon, nous attraperions les cas extrêmes pour nous assurer que le modèle prend en charge les limites de l'application.
Donc, fondamentalement, nous masserions le modèle jusqu'à ce qu'il prenne vraiment en charge les exigences commerciales et non fonctionnelles du système en utilisant un processus itératif jusqu'à ce que nous ayons fait évoluer un modèle en quelque chose que nous pouvons tous accepter malgré les compromis qui y sont intégrés.
Comme je l'ai dit, ce serait un processus très itératif qui pourrait se poursuivre sur plusieurs mois pendant que le code d'application, les interfaces utilisateur et les interfaces d'application sont en cours de développement.
Limites des commentaires bien intentionnés
Dans la situation actuelle des blogs, si mon nombre certes limité de lecteurs me fournit des commentaires sur les problèmes et les défis qu'ils observent avec les modèles, c'est nécessairement superficiel. Je doute que l'un des lecteurs utilise directement les modèles pour créer une application et découvrir ce qui fonctionne vraiment et où il y a des problèmes.
Ainsi, les commentaires tels que « le modèle n'est pas bien pensé » sont presque certainement corrects. D'un autre côté, "il manque des FK" sont assez précis, mais j'espère avoir expliqué dans le texte de l'article pourquoi j'inclus ou non une clé étrangère.
Conclusion
Maintenant, s'il vous plaît, ne lisez pas ce message comme une plainte ou un commentaire sur les commentaires des lecteurs, je réfléchis plutôt à la difficulté de créer un modèle de base de données lorsque vous n'êtes pas dans un environnement qui permet un échange interactif avec un itératif processus de développement.
Il existe probablement d'autres situations où les modélisateurs de bases de données sont coupés du processus de développement, mais j'ai maintenant réalisé à quel point cela serait dangereux et à quel point ils seraient sujets à des problèmes.
Pouvez-vous imaginer un modèle de base de données qui ne soit jamais modifié ? Jamais un seul ajustement d'une colonne, jamais l'ajout d'une clé étrangère, jamais le besoin d'une nouvelle table. Honnêtement, la seule situation que je peux imaginer comme ça, c'est quand l'application utilisant la base de données n'évolue plus et arrive dans une impasse :la fin de vie.
