Je travaille avec une base de données SQL Server avec plus de 1000 tables, quelques centaines de vues et plusieurs milliers de procédures stockées. Nous envisageons de commencer à utiliser Entity Framework pour nos nouveaux projets et nous travaillons à notre stratégie pour le faire. Ce que je raccroche, c’est la meilleure façon de scinder les tables en différents modèles (EDMX ou DbContext si l’on passe au code en premier). Je peux penser dès le départ à quelques stratégies:
- Divisé par schéma
Nous avons nos tables divisées en probablement une douzaine de schémas. Nous pourrions faire un modèle par schéma. Ce n'est pas parfait, cependant, car dbo finit toujours par être très volumineux, avec plus de 500 tables / vues. Un autre problème est que certaines unités de travail finiront par effectuer des transactions couvrant plusieurs modèles, ce qui ajoute à la complexité, bien que je suppose que EF rend cela assez simple. - Diviser par intention
Au lieu de se préoccuper des schémas, divisez les modèles par intention. Nous aurons donc différents modèles pour chaque application, projet, module ou écran, en fonction de la granularité souhaitée. Le problème que je vois avec ceci est que certaines tables doivent inévitablement être utilisées dans tous les cas, telles que User ou AuditHistory. Est-ce que nous les ajoutons à chaque modèle (viole DRY je pense), ou sont-ils dans un modèle séparé utilisé par chaque projet? - Ne divisez pas du tout - un modèle géant
Ceci est évidemment simple du point de vue du développement, mais d'après mes recherches et mon intuition, il semble que les performances puissent être terribles, à la fois au moment de la conception, de la compilation et éventuellement de l'exécution.
Quelle est la meilleure pratique pour utiliser EF avec une base de données aussi volumineuse? Quelles stratégies utilise-t-on spécifiquement dans la conception de modèles pour ce volume d’objets de base de données? Y a-t-il des options pour lesquelles je ne pense pas que cela fonctionne mieux que ce que j'ai ci-dessus?
En outre, est-ce un problème dans d'autres ORM tels que NHibernate? Si oui, ont-ils trouvé de meilleures solutions que EF?