Méthode à adopter : Entity Framework - 500 tables

Bonjour,

Je me demandais quelle était la meilleure façon d'architecturer un projet où l'on utilise Entity Framework avec un nombre très important de tables (entre 500 et 1000) ?

Pensez-vous qu'un unique fichier edmx suffit ? n'est-ce pas difficilement maintenable ?
Pensez-vous qu'il faille segmenter en plusieurs edmx ? dans ce cas, comment pourrait-on gérer des interdépendances entre ces edmx ? (c'est-à-dire si une table d'un fichier edmx a besoin d'une table d'un autre edmx)
Autre ?

Merci d'avance pour votre aide

Laurent

Déjà je suis pas convaincu qu'Entity Framework soit adapté pour un aussi grand nombre de tables ; mais bon, c'est juste une intuition, j'ai pas d'éléments concrets pour le justifier...

Ce qui est quasiment certain, c'est que si tu as un seul EDMX avec tes 500 tables, le designer va jamais s'en sortir... au mieux, ça va tellement ramer que ce sera inutilisable, au pire ça va péter avec une OutOfMemoryException. Par contre, tu pourrais envisager l'approche Code First, où il n'y a pas de modèle EDMX mais des mappings définis dans le code. A mon avis c'est une approche beaucoup plus souple et plus facile à maintenir.

Sinon, une autre approche serait de découper le modèle en domaines indépendants plus petits

Le post de Matthieu Mezil intitulé Comment découper ses entités en plusieurs modèles devrait t'aider

Son Edm Designer
http://edmdesigner.codeplex.com/

Comme la dit Tomlev je ne suis pas sûr qu'EF soit la méthode la plus adaptée. Pour les gros modèles je pense que des outils comme CodeFluent Entities sont plus adaptés.

@Tomlev : Oui effectivement pour le designer je pense qu'il pourrait difficilement supporter un trop grand nombre d'entités, c'est pour cela que l'on se posait la question de découper le modèle en plusieurs sous-modèles.

D'ailleurs j'ai trouvé quelque chose qui s'appelle Entity Designer qui, apparemment, permet de faire plusieurs diagrammes dans un même fichier edmx. Quelqu'un aurait-il testé ou entendu parlé ?
http://blogs.msdn.com/b/efdesign/arc...s-preview.aspx

Je me penche également sur Code First.

A ma boite on utilisait XPO de DevExpress qui ne posait pas tant de soucis, mais EF apporte des choses dont on aurait besoin.

Merci Meziantou, est-ce qu'au final, découper le modèle en plusieurs fichiers edmx ne risque pas d'apporter beaucoup de problèmes ? cela me parait assez périlleux

On parle de 500 tables dans le même schéma ?
Si oui ça me surprend... c'est du bancaire ?
Si non il y a une découpe qui semble assez évidente...

Pour Entity Framework, outre le côté Designer, ça va dépendre aussi de l’entremêlement entre tes tables. Si elles sont toutes liées entres elles, ça risque d'être assez peu performant.

C'est un projet qui n'est pas encore commencé, justement on essaie de voir quel ORM choisir. Evidemment il y a possibilité de découper, mais on se posait la question concernant les tables qui seraient communes entre plusieurs schémas, si cela ne posait pas de problème au niveau des requêtes et de la mise à jour des tables (en cas de modification d'une table, si on devait répercuter les changements dans chacun des fichiers de modélisation)

Citation:

---

Envoyé par Er3van

On parle de 500 tables dans le même schéma ?
Si oui ça me surprend... c'est du bancaire ?

---

Dans mon premier boulot, j'ai bossé avec un progiciel de facturation pour la téléphonie mobile... Il y avait environ 1200 tables dans la DB :aie:
(toutes dans le même schéma bien sûr ; pour couronner le tout, la plupart des tables avaient des noms super explicites, genre MPSSVTAB, MPUSNTAB, MPULKNXV... ceux qui ont utilisé le progiciel en question devraient reconnaitre ;))


Donc oui, ça existe... et c'est probablement pas si rare dans des systèmes complexes

Nous développons un progiciel pour la gestion de domaines viticoles, donc nous risquons d'avoir pas mal de centaines de tables effectivement.

J'aimerais maintenant avoir votre avis quel choix feriez-vous parmi les suivants ?

1. Entity Framework 4.1 en mode designer : plusieurs edmx découpés en fonction de schémas/modules
2. Entity Framework 4.1 avec Code First
3. Entity Developer (logiciel de gestion d'entités)
4. XPO de DevExpress
5. Autres...

En partant du fait que l'on aura une grosse volumétrie en termes de nombre de tables

Citation:

---

Entity Framework 4.1 en mode designer : plusieurs edmx découpés en fonction de schémas/modules

---

Je disais juste que c'était faisable. Après ca reste assez périlleux car il s'agit de bidouille.

Citation:

---

Entity Framework 4.1 avec Code First

---

Faisable mais long étant donnée le nombre de tables.

Citation:

---

Autres...

---

Je conseils toujours CodeFluent Entities qui te permettra de gagner beaucoup de temps de dev

Un grand nombre de table n'est pas un prérequis sur un progiciel hein :P
On peut développer une appli assez complexe sans nécessiter un schéma si complexe. Vous avez un DBA dans votre équipe?

Citation:

---

Envoyé par meziantou

Faisable mais long étant donnée le nombre de tables.

---

Pas si tu mappes les tables au fur et à mesure des besoins...

Tous les outils CodeFluent sont extrêmement chers, donc nous n'optons pas pour leurs solutions :/

Pas de DBA en particulier dans l'équipe non, mais on a besoin d'un certain nombre de tables vu la complexité apparente de la future application.

A priori d'après toi Tomlev ca serait plutôt code first ?

Est-ce que vous connaissez XPO ?

Citation:

---

Envoyé par marcusien

Pas de DBA en particulier dans l'équipe non, mais on a besoin d'un certain nombre de tables vu la complexité apparente de la future application.

---

Si la base va vraiment être complexe, ce serait vraiment mieux qu'elle soit conçue par un spécialiste... La plupart des développeurs ne sont pas expert en conception de BDD, et ça peut donner un résultat assez catastrophique qui sera super difficile à maintenir et à faire évoluer.

Citation:

---

Envoyé par marcusien

A priori d'après toi Tomlev ca serait plutôt code first ?

---

Bah j'ai pas trop creusé la question, mais à première vue c'est ce que je choisirais... Tu peux aussi regarder du côté de NHibernate (éventuellement avec Fluent NHibernate, qui en quelque sorte est à NHibernate ce que Code First est à Entity Framework)

Citation:

---

Envoyé par marcusien

Est-ce que vous connaissez XPO ?

---

C'est l'ORM de DevExpress, non ? Jamais utilisé...

Citation:

---

Envoyé par marcusien

Tous les outils CodeFluent sont extrêmement chers, donc nous n'optons pas pour leurs solutions :/

---

J'ignore la complexité de ton projet, mais à priori, si il y a 500 tables, je doute fort qu'il ne s'agisse que de 50 ou 100 jh. Donc, j'avoue que je ne comprends pas trop bien l'influence que peut avoir dans ce cas le prix de ces outils sur le budget global.

Citation:

---

Pas de DBA en particulier dans l'équipe

---

Sans vouloir être mauvaise langue, je sens un mauvais départ, là.

Citation:

---

Envoyé par Nathanael Marchand

Un grand nombre de table n'est pas un prérequis sur un progiciel hein :P
On peut développer une appli assez complexe sans nécessiter un schéma si complexe.

---

C'est un fait, mais on ne peut pas vraiment inverser l'affirmation.

Si une apppli peut éventuellement être complexe avec un schema de DB simple, il est difficile d'avoir une appli simple avec un schema complexe; or, je n'ai jamais vu un schema à plus de 500 tables qui soit simple.

Citation:

---

J'ignore la complexité de ton projet, mais à priori, si il y a 500 tables, je doute fort qu'il ne s'agisse que de 50 ou 100 jh.

---

Je suis assez d'accord avec bluedeep sur ce point. Est ce que payer un consultant DBA quelques temps, même à 2 ou 3kE la journée serait une économie par rapport au temps que vous risquez de perdre à bidouiller cette même base.

Si vous partez sur une base de 1 ou 2k jh, autant ne pas en dépenser 100 à faire un modèle bancal sans expert ;p

Bonjour,

Je me permets d'intervenir directement compte tenu de l'argument "extrêmement cher" évoqué dans cet échange pour écarter CodeFluent Entities.

Notre expérience des projets de ce type est la suivante :
- Un projet à 500 tables réalisé sans outil élevant le niveau d'abstraction coûte au final en général environ 4 à 5 K€ par table suivant la complexité du métier. Ce sont d'ailleurs les abaques des sociétés de services (un peu plus compliqué dans le détail mais c'est l'ordre de grandeur). On parle donc certainement d'un projet dont le budget est probablement 2 M€ ou plus.
- Le retour d'expérience de nos clients sur des projets de cette envergure est un coût moyen compris entre 2 et 3 K€ par table grand maximum (sans même parler du gain de maintenance qui est en fait le point fondamental compte tenu de la rapidité d'évolution des technologies).

On a donc probablement un retour sur investissement immédiat qui se situe entre 500 K€ et 1 M€ sur la seule phase de développement.

Un projet de ce type nécessite probablement une équipe de 5 à 10 développeurs et un coût de licence global pour l'équipe compris entre 20 K et 50 K€ suivant les options retenues.

Le décideur qui détient le chéquier ne mettra pas longtemps à approuver à partir du moment où il aura pu vérifier ces gains, par exemple sur la base d'un prototype. L'architecte en charge du projet porte certainement la responsabilité d'au moins proposer ces solutions, quitte à les écarter pour le projet en question sur la base d'arguments étayés par un prototype.

D'ailleurs, pour la petite histoire, les retours que nous avons des clients Entreprise sont plutôt que notre produit n'apparait "pas assez cher" pour ce qu'il fait. Nous avons "dû" créer une licence plus chère pour pouvoir remonter sur certains projets plus critiques et apparaitre crédible.

Quant à Entity Framework pour un projet de ce type, je vous souhaite bon courage.

Cette technologie n'a pas été éprouvée sur des projets de cette ampleur (et d'ailleurs globalement les ORMs atteignent en général leurs limites) et il y a des tas de problématiques que vous rencontrerez au cours du projet :
- Découpage du schéma pour travailler à plusieurs
- Manque de certaines fonctionnalités critiques
- Performance du visualiseur graphique
- Maitrise des requêtes générées en production (les DBA détestent les ORM, souvent à raison)
- Problématiques de verrouillage
- Mise à jour de la base de données dans un modèle qui va forcément évoluer (ce point d'évolution différentielle est totalement transparent avec CFE)

Pour les personnes techniques qui lisent l'Anglais, je conseille ce document http://www.codefluententities.com/do...0Framework.pdf . A la fin, vous y trouverez un ensemble de questions majeures posées sur Stack Overflow par de vrais développeurs, confrontés aux vrais problèmes, et auxquelles aucune réponse n'est apportée aujourd'hui. Il est très probable que vous arriviez dans les mêmes impasses avec votre projet.

Donc, sans même parler du coût, je ne conseillerai pas de partir sur Entity Framework pour un projet de ce type. Les ORM sont bien pour de petits développements où le développeur peut totalement s'abstraire des problématiques de base de données.

Et nous avons chez SoftFluent plus de 50 ans de présence cumulée au sein de la société Microsoft... donc pensez bien que si nous pouvions faire reposer l'accès aux données sur Entity Framework aujourd'hui, nous le ferions bien volontiers !

Daniel COHEN-ZARDI, Président de SoftFluent

Je ne me prononcerai pas sur CFE que je n'ai jamais utilisé, je voudrais juste tordre le cou à un préjugé:

Citation:

---

Envoyé par SoftFluent

- Maitrise des requêtes générées en production (les DBA détestent les ORM, souvent à raison)
Les ORM sont bien pour de petits développements où le développeur peut totalement s'abstraire des problématiques de base de données.

---

Sans vouloir rentrer dans le fameux troll ORM/pas ORM (qui a déjà sévi plusieurs fois sur ce forum), voici mon opinion:
Oui oui, des gros projets s'en sortent aussi avec des ORM (effectivement, pas forcément EF et y'a pas de designer).
Lorsqu'il me génère une requête, celle ci est générée de manière déterministe: deux fois la même requête en ORM dans le même contexte donne deux fois la même requête SQL (sinon l'ORM est à jeter :aie:)
Je peux aussi avoir la main sur le SQL et éventuellement faire une requête optimisée à la main (un MERGE ou rajouter un hint).

Les DBA ont raison de détester les ORM lorsqu'ils sont utilisés par des débutants. Les DBA auraient tort de détester les ORM lorsqu'ils sont utilisés intelligement.

Et pour cloturer, version philosophie de comptoir, voici un proverbe:

Citation:

---

Il n'y a pas de mauvais outils, que de mauvais ouvriers.

---

+1 pour Nathanaël, mais je crois qu'on a effectivement déjà beaucoup débattu sur le sujet ;)

Pour revenir sur ce qui est dit plus haut, je pense que le gros problème, c'est qu'on ne sait pas où tu veux aller marcusien.
Il faudrait qu'on ait plus de billes sur le projet en question pour pouvoir te donner un avis pertinent.

Ce n'est pas parce qu'on a pu éventuellement conseiller dans un contexte précis l'utilisation d'EF ou CDE (ou whatever) que ce conseil peut se transposer sur ton projet !

PS : Autre proverbe de comptoir :

Citation:

---

Un bon ouvrier travaille toujours avec de bons outils

---

Merci pour toutes ces réponses assez constructives.

Pour expliquer la situation brièvement, je ne suis que développeur dans une PME comptant actuellement 3 développeurs, aucun DBA et un chef de projet fonctionnel + le directeur technique qui joue le rôle de chef de projet fonctionnel et un peu technique.
Je ne connais pas bien encore le projet sur lequel nous allons travailler. Je parle de 500 tables car c'est une fourchette que l'on m'a donné, ça peut être moins ou plus. Le contexte c'est un progiciel de gestion de domaines et négociants en vins. Gestion commercial, des stocks et des imports/Exports etc.

Concernant CFE, il faut que je vois avec les décideurs si cette solution est envisageable. Le problème est que nous ne connaissons pas l'outil pour un projet dont la deadline est dans un an environ. Pour le moment, pour d'autres projets assez complexes, nous utilisions XPO de DevExpress qui fonctionne relativement bien et qui fonctionne selon le même principe que CodeFirst (coder les classes en c# puis génération/modification de la base au lancement de l'application)

Dans tous les cas, je prend en considération les conseils concernant un DBA. Je ne sais pas si cela se ferait mais on verra bien.
Pour le moment je suis plus ou moins en charge d'étudier les diverses solutions qui pourraient s'offrir à nous concernant un ORM permettant de gérer des bases de données volumineuses en termes de data pures et de nombre de tables.
En tout cas, en développement, se passer d'un ORM pour un grand nombre de tables, c'est du suicide, n'en déplaise aux DBA ^^