Bonjour,
je dois commencer un nouveau projet et je suis en train de me poser les question d'architecture DB avant de commencer (et oui, de temps en temps, on réfléchit ;o))
Bref, c'est une appli pour plusieurs centres qui ont les mêmes articles (enfin presque) et les mêmes clients. Donc une table article et client commune (ok, facile).
Mais par contre, toutes les ventes sont spécifiques à un centre. Il faut pouvoir avoir l'historique d'un article ou d'un client (inter centre). Mais la table va grossir très vite vue le nombre de vente qu'il y a par jour. Multiplié par le nombre de centre, cela va vite ralentir le système. L'ancien système (désuet) avait une db par centre. mais impossible (sans grosse fusion des tables avant) d'avoir rapidement les données statistiques des ventes d'un produits ou d'un client intercentre.
Je me suis dit que peut-être les vues permettrait d'avoir rapidement les données d'un centre (mais attention aux insert et update) si on les filtres par clé de centre. Tout en laissant la possibilité de faire des requêtes intercentre pour les statistiques.
Ou alors on fait une table vente par centre et des unions quand on veut avoir les données groupées.
qu'en pensez-vous? Quelle est la meilleurs architectures à votre avis (ou une autre idée à laquelle je n'aurais pas pensé)
Merci d'avance
Partager