Discussion :

[Guido SAvi]

Bonjour à tous,

je cherche une astuce pour faire un développement multi sociétés sous WinDev 17.
Voici la problématique:
- un seul serveur avec une base de données centrale
- plusieurs sociétés peuvent se connecter au serveur
- chaque société ne voit que ses propres données

[tatayo]

Bonjour,
Le plus simple est d'associer les données à un code société, puis de filtrer sur ce code.
Par exemple, chez nous un magasin est associé à une société.
Quand on est connecté à l'application, les magasins sont filtrés sur le code société.
Si on veux voir les tickets de vente, on ne voit que ceux associés aux magasins auxquels on a accès, selon la société donc. Mais pour autant on n'a pas de code société dans les tickets de vente.
Il en va de même pour le reste des données.
Pour ce qui est des articles, qui peuvent être commun (cas des franchisés), on a une table qui indique par article quelle société est "autorisée" ou pas à l'utiliser.
Donc tout dépend si l'association "ressource"/société est intrinsèque (cas des ventes) ou paramétrable (articles).

Tatayo.

[laurent30s]

Outre la méthode expliquée par Tatayo il y a la solution de créer un répertoire différent par société.

En principe on a un répertoire modèle où figure tous les fichiers de l'appli avec seulement des données de bases communes à toutes les sociétés.
Lors de la création d'une société, ajout d'un répertoire où on y copie tous les fichiers du répertoire modèle.

A l'ouverture de l'appli l'utilisateur choisi la société sur laquelle il veut travailler (seules les société pour lesquelles il est autorisé lui sont proposées). Et l'appli travaille sur les données du répertoire correspondant à la société.

Cette méthode est utilisée par de nombreux logiciels de gestion. Elle offre l'avantage que les données de sociétés différentes sont complètements séparées...

[cladoo]

Personnellement, je travaille sous mySQL et j'ai une base d'administration qui contient les identifiants de connexion de chaque client (serveur, base, login,...) et chaque client a sa propre base, ça permet effectivement de séparer de manière claire les données entre les clients, et éviter d'oublier de poser un filtre lors d'une requête si on a tous les clients dans la même base.
C'est simple et efficace.

Autre avantage : en terme de rapidité d'exécution des requêtes, j'ai souvent à faire des jointures sur une bonne dizaine de tables dont certaines contiennent plusieurs millions d'enregistrements. Le fait de scinder 1 client / 1 base : on ne multiplie pas le nombre de lignes d'une table par le nombre de client.

[tatayo]

Je suis d'accord avec vous, mais:

- un seul serveur avec une base de données centrale

Tatayo.

[SevenSoftware]

Bonjour,

Les 2 solutions ont leurs avantages et leurs inconvénients.
Il faudrait préciser le projet...

Si les "sociétés" sont des clients qui n'ont aucun rapport entre eux, la
solution des bases séparées tient la route, notamment pour les raisons invoquées par Cladoo. (Ces bases pouvant être sur le même serveur pour tenir compte de la remarque de Tatayo)

Par contre, si les sociétés font partie d'un même groupe par exemple, pas d'hésitation: une seule base avec un code société: on peut éventuellement avoir besoin de chiffres consolidés.
L'argument de performance évoqué par Cladoo dépend de la base de données retenue et du dimensionnement du serveur... Là, c'est plus une question de budget.

[laurent30s]

Bonjour,

Les 2 solutions ont leurs avantages et leurs inconvénients.
Il faudrait préciser le projet...

Si les "sociétés" sont des clients qui n'ont aucun rapport entre eux, la
solution des bases séparées tient la route, notamment pour les raisons invoquées par Cladoo. (Ces bases pouvant être sur le même serveur pour tenir compte de la remarque de Tatayo)

Par contre, si les sociétés font partie d'un même groupe par exemple, pas d'hésitation: une seule base avec un code société: on peut éventuellement avoir besoin de chiffres consolidés.
L'argument de performance évoqué par Cladoo dépend de la base de données retenue et du dimensionnement du serveur... Là, c'est plus une question de budget.

Patrick a tout est dit, c'est le contexte qui guide choix...