Discussion :

[eponette]

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

[ylarvor]

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))

On est là pour ça. en effet.

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).

OK.

Mais la table va grossir très vite vue le nombre de vente qu'il y a par jour.

Tu as de la chance, il y a un système existant qui te permet de chiffrer la croissance journalière de la table et annuelle. Tu peux donc dimensionner ta base pour les 3 prochaines années à l'aide de power amc.

Multiplié par le nombre de centre, cela va vite ralentir le système.

Il faut se donner les moyens de ses exigences, à base de grande dimension, serveur de grande dimension. Après avoir dimensionner ta base, tu dois dimensionner ton futur serveur pour la taille de ta base de données et pour répondre aux accès concurrents que ne manqueront pas de faire les différents magasins.

A ce niveau, j'ai quand même un doute, moi aussi... Je sais qu'il existe des bases de données de plusieurs tera-octets, là dessus, pas de problème. Mais Comment un serveur unique peut répondre à un trés trés grand nombre de demandes ? A mon tour d'être interogatif ?

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.

OK.

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.

Une vue MONCENTREA permet en effet de voir les données du centreA. Tu peux donc écrire tes requêtes vers la vue MONCENTREA comme si il avait une existence physique.

(mais attention aux insert et update)

Une vue ( si elle n'est pas indexable ) n'est pas matérialisée, les données vont être cherchés à chaque fois par conséquent, aucun soucis pour les insert et les update, ils sont toujours à jour.

Ou alors on fait une table vente par centre et des unions quand on veut avoir les données groupées.

Cette solution ne me semble pas respecter l'éthique de conception d'une base de données. Je me trompe peut être.

De toute façon, je pense qu'il est plus efficace de faire une vue en restriction ( table unique avec idcentre ) qu'une vue en union ( tables centres multiples ).

Ensuite, le problème des accès concurrents nombreux à la base se posera quand même puisque les tables sont dans la même base.

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

La solution de la table unique pour l'ensemble des centres me parrait une bonne idée. Il suffit de dimensionner.

[Alain Defrance]

Bonjour,

Je pense que l'utilisation d'une vue par centre est tout a fait correcte.
A savoir que lorsque tu fait une modification sur une vue elle est faite aussi sur la table source, tu n'as pas de souci a te faire pour les insert et les update. Par contre attention si ta vue a été construite avec des jointures tu ne pourra pas effectuer ces opérations, mais dans ton cas puisque tu veux utiliser une vue pour récupérer seulement une partie d'une table il n'y a pas de problèmes.

La question est plutôt de savoir si la base de donnée sera seulement volumineuse, où bien alors elle devra gérer beaucoup d'accès concurrents.

Si elle est seulement volumineuse il n'y a pas de problèmes, en revanche si tout tes centres l'utilise de manière intensive en même temps, il faudrait en effet répartir la charge en plusieurs serveurs avec des réplications.

[SQLpro]

A ce niveau, j'ai quand même un doute, moi aussi... Je sais qu'il existe des bases de données de plusieurs tera-octets, là dessus, pas de problème. Mais Comment un serveur unique peut répondre à un trés trés grand nombre de demandes ? A mon tour d'être interogatif ?

Parallélisme + granularité du verrouillage...

Plus il y a de proc en // plus de clients peuvent être servit simultanément.

Plus le verrouillage porte sur une donnée fine, plus de clients peuvent être servit simultanément.

Il faut bien entendu dimensionner correctement le serveur.
Par exemple sous SQL Server il faut environ 1 carte réseau et 1 proc par 1000 à 2000 utilisateurs.
Pour les plus grosses solution on tourne à 35 000 utilisateurs simultanément (exemple serveur Eurydile du registre du commerce).

A +

A