Bonjour
Citation:
Envoyé par
NicoL__
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.
Citation:
Envoyé par
NicoL__
Il est préférable de faire un schéma par ensemble de responsabilité (facturation, référentiel client, catalogue produit...).
Pourquoi pas ....
Citation:
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.
Citation:
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.
Citation:
Cela permettra de bien séparer les infrastructure extranet et intranet (oui même au niveau des BDD ça peut éviter un risque).
Lequel ?
Citation:
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).
Citation:
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.
