Discussion :

[M_Makia]

Bonjour à tous,

Je souhaiterais avoir vos avis concernant la meilleure architecture à suivre pour un projet qui est en cours d’étude.
Le projet consiste à développer une suite d'applications web MVC (intranet ou extranet selon les applications).

Typiquement il y aura :
-une appli pour gérer les contacts client
-une appli pour gérer les devis et la facturation
-une appli pour gérer un catalogue produit
-une appli pour administrer l’authentification aux différentes applis
-une appli SAV
- ect ... (d'autres applis viendront se rajouter dans le futur)

On peut estimer que la majorité des applications fonctionneront avec un ou plusieurs référentiels de données communs (par exemple le référentiel client qui sera lié à la facturation et au SAV).

Voici mes questions :

Est-il mieux de mettre les données de toutes les applications dans une même BDD ?
Avantages ? Inconvénients ?

Est-ce que d’après vous Entity Framework est adapté à ce type de projet ?
Si non quels options envisageriez-vous pour l’accès aux données ?

Merci pour vos retours.

[Nathanael Marchand]

Est-il mieux de mettre les données de toutes les applications dans une même BDD ?

Oui

Avantages ? Inconvénients ?

Simplicité d'utilisation. Pas sur qu'un besoin de découpage en plusieurs bases soit pertinent. Gérer des relations et notamment des contraintes d'intégrité entre bases de données c'est pas de la tarte.

Est-ce que d’après vous Entity Framework est adapté à ce type de projet ?

Il n'y a pas de raisons que ca ne fonctionne pas, la bête commence à être mature et l'intégration avec ASP.Net MVC est bien faite.

Si non quels options envisageriez-vous pour l’accès aux données ?

NHibernate pour rester dans les ORM. Ou sinon plusieurs autres solutions sont possibles (générateurs de DAL par exemple).

[NicoL__]

Bonjour,

Je ne suis pas du tout de ton avis pour mettre toutes les données dans la même BDD, en tout cas si je comprends par BDD est un schéma.
Il est préférable de faire un schéma par ensemble de responsabilité (facturation, référentiel client, catalogue produit...).
Et les données ne sont pas si liées que cela.
Par exemple une facture dans la facture il faut RECOPIER les données du catalogue et du client (prix, description, adresse...) car une facture émise ne change plus alors que l'adresse du client et les prix du catalogues vont être modifiés au cours du temps voir des produits retirés...
De même l'administration et l'authentification se fait de manière indépendante dans un LDAP auquel on peut associer une base de données pour gérer les information de profil utilisateur.
Cela permettra de bien séparer les infrastructure extranet et intranet (oui même au niveau des BDD ça peut éviter un risque).
Idéalement chaque application a sa base de données avec un accès écriture et lecture, et peut interroger les données des autres base au travers de services (web service par exemple) fourni par l'application responsable de la base de données.
Mais bon c'est toujours un peu plus lourd de bien faire les choses... tout mettre à la va vite dans la même base avec N applications qui vont écrire un peu n'importe où et consulter les données n'importe comment est la norme...
Sinon EntityFramework c'est pas mal et le MVC made in Microsoft est aussi abouti.

[Nathanael Marchand]

Ah mais c'est pas parceque ce sont plusieurs applications du point de vue utilisateur qu'il n'est pas possible d'avoir une couche de services unifiée derrière

[BenoitM]

Bonjour,
Idéalement chaque application a sa base de données avec un accès écriture et lecture, et peut interroger les données des autres base au travers de services (web service par exemple) fourni par l'application responsable de la base de données.
Mais bon c'est toujours un peu plus lourd de bien faire les choses... tout mettre à la va vite dans la même base avec N applications qui vont écrire un peu n'importe où et consulter les données n'importe comment est la norme...
Sinon EntityFramework c'est pas mal et le MVC made in Microsoft est aussi abouti.

Ce n'est pas parce que tes données sont séparés que ca t'empeche de developper avec des pieds et inversément

Perso je vois plus de risque et de complication que d'avantage.
Peut-être plus de facilite en cas de recherche de plus de performance: tu pourras plus facilement repartir la charge sur plusieurs machines

Par exemple une facture dans la facture il faut RECOPIER les données du catalogue et du client (prix, description, adresse...) car une facture émise ne change plus alors que l'adresse du client et les prix du catalogues vont être modifiés au cours du temps voir des produits retirés...

euh j'espere que tu ne vas pas sauvegarder un produit à chaque facture
Le versionning ca existe et même dans le cas de base séparée tu as interêt à utiliser cette technique.

[NicoL__]

Je pense que séparer les responsabilité permet de mieux gérer les choses et le faire avec les base de données me semble le bon sens. Cale simplifie les déploiement, et le travail en équipe.
Après

Ah mais c'est pas parceque ce sont plusieurs applications du point de vue utilisateur qu'il n'est pas possible d'avoir une couche de services unifiée derrière

Je sais pas si c'est top un service unifié pour la maintenance et les déploiements... enfin de toute façon c'est pas un problème on peut faire un service unifié s'appuyant sur plusieurs BDD.

Bref on arrive toujours faire du code qui fonctionne, mais c'est plus dur de faire un code lisible et maintenable et compréhensible. Une première approche est de bien séparer les responsabilités pour pas se retrouver avec des régressions tout le temps.

Perso je vois plus de risque et de complication que d'avantage.

Oui c'est vrai tout dépend de la vision et des perspectives du projet si c'est un projet d'école, oui le plus simple c'est de faire une base de données unique, c'est sûr...

euh j'espere que tu ne vas pas sauvegarder un produit à chaque facture

Oui c'est un peu violent comme idée mais il y a une parti à recopier. La foreign key du produit + la quantité ne permet de reconstituer une facture en réalité. A priori je dirais que ce qui peut-être imprimé sur une facture doit être enregistré en base et non reconstitué par une requête dans le catalogue produit.
Après du versioning, oui pourquoi pas c'est une approche, plus complexe qu'il n'y parait à mon sens pour résoudre ce problème et va en entraîner bien d'autres...

[Bluedeep]

Bonjour

Je ne suis pas du tout de ton avis pour mettre toutes les données dans la même BDD, en tout cas si je comprends par BDD est un schéma.

Déjà, non. Tu peux avoir n schéma par BDD.

Il est préférable de faire un schéma par ensemble de responsabilité (facturation, référentiel client, catalogue produit...).

Pourquoi pas ....

Et les données ne sont pas si liées que cela.
Par exemple une facture dans la facture il faut RECOPIER les données du catalogue et du client (prix, description, adresse...) car une facture émise ne change plus alors que l'adresse du client et les prix du catalogues vont être modifiés au cours du temps voir des produits retirés...

Typiquement, on a une table d'en tête de facture et une table de lignes de factures, qui effectivement vont contenir des données potentiellement dupliquées.

De même l'administration et l'authentification se fait de manière indépendante dans un LDAP auquel on peut associer une base de données pour gérer les information de profil utilisateur.

Là on ne voit pas du tout le rapport entre le LDAP et le choix entre BDD unique ou multiple.

Cela permettra de bien séparer les infrastructure extranet et intranet (oui même au niveau des BDD ça peut éviter un risque).

Lequel ?

Idéalement chaque application a sa base de données avec un accès écriture et lecture, et peut interroger les données des autres base au travers de services (web service par exemple) fourni par l'application responsable de la base de données.

Ce poitn de vue est tout à fait discutable : je ne vois pas de bénéfice à faire intervenir des entités tiers si c'est simplement pour fournir de la donnée, sans traitement métier. Par exemple, dans le cas que tu cites supra (séparation intranet vs extranet) l'usage de deux BDD est une option mais l'usge de tiers type web service pourra être avantageusement remplacé par des systèmes de réplication (à voir au cas par cas, mais affirmer une règle générale dans ce cas me semble franchement outrancier).

Mais bon c'est toujours un peu plus lourd de bien faire les choses... tout mettre à la va vite dans la même base avec N applications qui vont écrire un peu n'importe où et consulter les données n'importe comment est la norme...
Sinon EntityFramework c'est pas mal et le MVC made in Microsoft est aussi abouti.

Dès l'instant où on spécialise les vues par application, je ne vois pas d'objection de principe à la BDD unique. Après il fait voir avec les volumétries, les contraintes de disponibilité, le nombre de tables, etc ... Si j'ai 5000 tables dans une BDD, je peux me dire que peut être aurai-je pu bénéficier d'une approche multi-base; si c'est pour se retrouver avec des BDD avec une dizaine de table chacune, c'est plus que discutable (du style les clients dans une base, la facturation dans une autre).
Tu vas crééer des contraintes d'administration sans bénéfice a priori.

[NicoL__]

Déjà, non. Tu peux avoir n schéma par BDD.

Oui c'est sûr. En fait j'entends BDD = schéma, c'est ce que j'ai écrit plus haut pour clarifier le sens de la question initiale.

[Bluedeep]

Oui c'est sûr. En fait j'entends BDD = schéma, c'est ce que j'ai écrit plus haut pour clarifier le sens de la question initiale.

Oui, mais là tu fabriques une contrainte qui n'existe pas :

1 serveur (machine) physique => n instances de SGBD.
1 instance => n bases
1 base => n schémas.