Est-ce que l'ORM habillé sur une mauvaise conception de base de données réduit son effet à l'application?

Question

Je travaille dans l'application .NET de taille moyenne qui a une conception de base de données très très mauvaise sinon pire, presque des tables ne font pas la normalisation et la conception complexe de table.

E.g. J'ai une table pour suivre le mouvement des stocks et chaque fois que je modifie ce tableau, j'ai besoin de mettre à jour la table de stock actuel. À mon avis, c'est un mauvais design, parce que je peux utiliser SUM quand je veux connaître le stock actuel. Un autre exemple, chaque fois que j'insère de nouvelles données de mouvement de stock, je n'insère pas directement à la table des mouvements de stock, j'insère des données au mouvement de stock temporaire et ensuite j'utilise tricker pour copier ces données tables (peut être mise à jour du crédit client). J'essaie d'adopter ORM avec cette application, mais il semble trop difficile pour moi, j'ai besoin de quelques heures pour créer mapping-class et quelques jours pour le tester, car la non-normalisation et la persistance des données vagues.

Je veux savoir, ORM peut-il réduire le problème d'une mauvaise conception de base de données comme celle-ci? Si oui, comment puis-je faire cela?

P.S. Je ne peux pas du tout modifier la conception d'une base de données, car presque tous les membres de mon équipe n'ont aucune idée du concept de la base de données.

Answer 1

Je ne pense pas. ORM et les objets ne sont pas magiques. Si vous les mettez au-dessus d'un mauvais design, c'est toujours un mauvais design.

S'il n'est pas impératif que toutes les mises à jour de stock apparaissent immédiatement, vous pouvez les mettre en file d'attente et les écrire de manière asynchrone. Mais c'est juste en train de papoter sur un problème potentiel.

Answer 2

Je vous recommande d'essayer de créer une image d'une conception de base de données corrigée dans la couche de données elle-même. Vous n'avez pas indiqué la base de données que vous utilisez, mais si vous utilisez SQL Server, vous pouvez essayer de créer des vues normalisées avec les déclencheurs INSTEAD OF UPDATE et INSTEAD OF INSERT. Lorsque vous écrivez un nouveau code, ciblez les vues normalisées au lieu des tables héritées. Au fil du temps, vous pouvez migrer votre code existant des tables mal conçues et les remplacer au cas par cas. Finalement, vous aurez une base de données bien conçue. Une remarque importante est que, bien que la normalisation soit une considération importante, vous devriez également regarder les entités de votre système pour vous assurer que le modèle conceptuel de la base de données est correct. En général, une base de données correcte au niveau conceptuel sera également conforme aux 1ers 3 formes normales, mais l'inverse n'est pas vrai (les formes normales ne garantissent pas l'exactitude conceptuelle). Si vous voulez entreprendre ce travail, vous voulez vous assurer que vous passez à la bonne conception pour votre système.

C'est certainement une bonne idée d'utiliser un ORM pour tout nouveau code d'accès à la base de données. Cela vous donne beaucoup de flexibilité à l'avenir. Ainsi, les étapes générales pour l'écriture de nouvelles fonctionnalités est:

1. Créer une façade au sein de la base de données qui présente un modèle de données approprié en utilisant des vues ou, si possible, en restructurant les tables. Ecrivez votre code ORM sur le modèle de données approprié.
2. Toujours chercher des opportunités pour faire évoluer votre modèle de données hors de son ornière actuelle.

Votre but ultime devrait être de refactoriser la base de données.Vous voudrez peut-être vous familiariser avec le travail de Scott Amber sur ce sujet.

Answer 3

Et ce n'est peut-être pas une mauvaise conception. Il y a des moments où les éléments sont précalculés afin que les rapports puissent s'exécuter sans expiration. Tout simplement parce que vous pouvez additionner un stock lorsque vous avez besoin de le voir sur l'interface utilisateur rapidement ne signifie pas que quelqu'un d'autre qui exécute un rapport qui résume toutes les actions n'aurait pas de difficulté à le faire en temps opportun. Il est souvent préférable de pré-calibrer certaines choses. Parfois, faire un calcul une fois vaut mieux que de le refaire chaque fois que cela est nécessaire. Je ne peux pas dire si c'est une bonne ou une mauvaise idée dans votre cas spécifique, je signale juste qu'il y a beaucoup de fois où c'est un bon design.

Il y a des raisons pour lesquelles le design est de cette façon, essayez de les trouver avant de décider que c'est un mauvais design. Vous pouvez toujours trouver qu'il y a un mauvais design, je dis juste ne supposez pas que c'est jusqu'à ce que vous compreniez la raison pour laquelle tout simplement parce que cela ne correspond pas à vos préférences personnelles. Si vous voulez vraiment reconcevoir la base de données (et avoir le feu vert de l'arrangement), alors lisez sur refactoring des bases de données (il y a de bons livres sur ceci) avant que vous essayiez de faire n'importe quoi. Il y a des choses qui doivent être considérées que les développeurs d'applications ne sont généralement pas au courant.

Answer 4

En général: non. Comme les autres l'ont souligné: Un ORM n'est qu'un outil pour refléter l'état et le design de la base de données au sein de votre application, adapté à votre langage de programmation.

Dans ce cas: probablement oui. Si vous créez un modèle de domaine enrichi, la méthode alterStockPortfolio (StockMovement s) peut être mise à jour (c'est-à-dire appeler les méthodes appropriées) les entités associées. Ajoutez les appels de méthode un par un lorsque vous supprimez les déclencheurs de base de données correspondants. Après quelque temps vous avez une application où la logique métier est dans le code du programme, où vous pouvez le gérer avec des tests unitaires. (Commencez par écrire ceux-ci).

Des valeurs dérivées de pré-calcul comme celle-ci sont souvent nécessaires pour surmonter les goulots d'étranglement des performances. Ce n'est pas nécessairement un mauvais design. Pourtant, la logique qui contrôle les valeurs persistantes dans la base de données ne devrait être que dans un seul endroit, sinon vous perdez le contrôle sur elle avec des changements apparemment aléatoires qui se produisent "dans le fond". À mon avis, un endroit devrait être le code de l'application.