A votre avis ...

Le
I.G.LOG
Bonjour,

Je développe actuellement une appli WD12 multi-sociétés. Toutes les données
sont dans la même base (MySQL 4.1).
Je suis donc obligé de gérer dans chaque table un pointeur sur la société à
qui appartient la donnée.
Ce n'est surement pas optimal au niveau du volume des données, et rend très
complexe les requetes puisque chacun d'elle doit faire le test sur ce
pointeur.
Les sociétés n'ayant à priori aucune données commune, je pensais créer une
base par société.
Mais, en environnement multi-utilisateurs, comment gérer le login des
utilisateurs afin qu'ils puissent choisir la société sur laquelle ils vont
travailler ?
Par exemple, comment remplir une combo-box avec le nom des sociétés et le
nom de la base concernée ?
Au niveau du serveur MySQL, comment reconnaître les bases qui m'
"appartiennent" et les autres ?

Pour résumer, quel principe appliqueriez vous pour gérer ce cas ?
Merci à tous
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Dc
Le #20412851
Bjr,

I.G.LOG a formulé la demande :
Bonjour,
Par exemple, comment remplir une combo-box avec le nom des sociétés et le nom
de la base concernée ?



Pour schématiser il faut :
- un fichier dans l'arborescence commune avec la liste de tes sociétés.
- une base pour chaque société sur laquelle on est dirigé apres le
choix.

a plus

--
-------------------------------------------------------------
www.ctc-soft.com
Gestion biblo-documentaire (free-share)
Comptabilité shareware
Logiciels de Gestion de saisie terrain
Spécialisé Tournées de boulangers
-------------------------------------------------------------
Roumégou Eric
Le #20414451
I.G.LOG a exprimé avec précision :
Bonjour,

Je développe actuellement une appli WD12 multi-sociétés. Toutes les données
sont dans la même base (MySQL 4.1).
Je suis donc obligé de gérer dans chaque table un pointeur sur la société à
qui appartient la donnée.
Ce n'est surement pas optimal au niveau du volume des données, et rend très
complexe les requetes puisque chacun d'elle doit faire le test sur ce
pointeur.
Les sociétés n'ayant à priori aucune données commune, je pensais créer une
base par société.
Mais, en environnement multi-utilisateurs, comment gérer le login des
utilisateurs afin qu'ils puissent choisir la société sur laquelle ils vont
travailler ?
Par exemple, comment remplir une combo-box avec le nom des sociétés et le nom
de la base concernée ?
Au niveau du serveur MySQL, comment reconnaître les bases qui m'
"appartiennent" et les autres ?

Pour résumer, quel principe appliqueriez vous pour gérer ce cas ?
Merci à tous



si tes utilisateurs sont sensés travailler sur toutes les sociétés, je
ne vois pas en quoi ton organisation actuelle pose problème ???
Les index sur le code société sont faits pour ça et c'est le principe
d'une base relationelle. Après cela n'a pas besoin d'être dans toutes
tes tables, tout dépend de ta modélisation.
Par contre si tu me dis que tes utilisateurs ont une et une seule base,
et une fois connectés ils ne travaillent que dans cette base, alors oui
pourquoi pas créer plusieurs bases.

Mais attention plus de bases, plus d'administration, plus de
sauvegardes etc ...

pour nous par exemple, nous avons plus d'une 30taine de base mysql
réparties sur 4 serveurs (plus des bases localhost de tests) mais pour
chaque base, cela peut correspondre à plusieurs dossiers. Donc nous ne
créons de nouvelles bases que par ce que c'est un client différent.
Mais à l'intérieur de cette base, nous gérons tous les dossiers
différents de ce client (et qui n'ont là aussi rien à voir).
Et pour la multi connexions bases, nous mettons la liste des bases
dispos dans un .ini.(donc specifiques par clients)
A la connexion, un treeview qui montre les serveurs et les bases
associées, et la personne sélectionne sa base sur un serveur donné. (la
plupart n'ont qu'une base/serveur) et donc accède directement. On
sauvegarde dans un .ini aussi la derniere base/serveur utilisée ainsi
que le dossier sur lequel ils ont travaillés, et donc ils arrivent
directement avec leur derniere sélection.

--
Eric Roumégou
Webmaster des wtablettes
http://cerbermail.com/?qE7t4Qvilo
(cliquez sur le lien ci-dessus pour me contacter en privé)
Goof
Le #20425541
Bonjour

Que ca soit en HF classique ou C/S.
l'option d'avoir une base donnée pour l'authentification et une base par
société s'impose relativement rapidement .
nous n'utilisons pas Mysql mais en HF C/S, nous utilisons une base pour
la gestion des utilisateurs/logs/gestion des droits et liste des société.
Après le login, on charge une base spécifique a la société en cours.
Et ca marche trés bien.
Pour changer de société, il suffit de changer la connexion Mysql des
fichiers de la société et c'est terminé.

Il est vrais que les interactions entre 2 société ne sont pas des plus
simple quand tout est cloisonné ainsi.
Mais la souplesse de maintenance et le fait d'être uniquement sur la
société en cours, est un vrai avantage dans 99.9% du code.

dans le systéme mono base,une erreur de manipulation/un crash disque ou
tout autre problème impacte toutes les sociétés.
Si une opération de maintenance doit être faite sur une société, on
bloque quand même les autre sociétés qui n'ont PE pas de problèmes.

A++
Goof
I.G.LOG
Le #20429681
"Goof" 4ae57078$0$949$
Bonjour

Que ca soit en HF classique ou C/S.
l'option d'avoir une base donnée pour l'authentification et une base par
société s'impose relativement rapidement .
nous n'utilisons pas Mysql mais en HF C/S, nous utilisons une base pour la
gestion des utilisateurs/logs/gestion des droits et liste des société.
Après le login, on charge une base spécifique a la société en cours.
Et ca marche trés bien.
Pour changer de société, il suffit de changer la connexion Mysql des
fichiers de la société et c'est terminé.

Il est vrais que les interactions entre 2 société ne sont pas des plus
simple quand tout est cloisonné ainsi.
Mais la souplesse de maintenance et le fait d'être uniquement sur la
société en cours, est un vrai avantage dans 99.9% du code.

dans le systéme mono base,une erreur de manipulation/un crash disque ou
tout autre problème impacte toutes les sociétés.
Si une opération de maintenance doit être faite sur une société, on bloque
quand même les autre sociétés qui n'ont PE pas de problèmes.




Merci pour cette réponse qui montre les avantages d'un système multi-base,
et auxquels je n'avait pas pensé. Je voyais surtout la difficulté de
porgrammation et de structure des tables, dans lesquelle doivent
invariablement exister un pointeur société: très (trop) lourd et donc
synonyme de bugs ; je vais probablement m'orienture sur cette voie, mais...
quelles peuvent être les "interactions" entre deux sociétés distinctes ?
Encore merci
I.G.LOG
Le #20429771
>
si tes utilisateurs sont sensés travailler sur toutes les sociétés, je ne
vois pas en quoi ton organisation actuelle pose problème ???



Bonjour,
Ca ne pose pas réellement de problème actuellement. Mais l'appli évolue en
permanence et je dois faire un choix !
J'ai de toute façon pu constater à quelle point l'option pointeur dans les
tables est lourde et génératrice de bugs, de complexité de programmation et
de maintenance.

Les index sur le code société sont faits pour ça et c'est le principe
d'une base relationelle. Après cela n'a pas besoin d'être dans toutes tes
tables, tout dépend de ta modélisation.
Par contre si tu me dis que tes utilisateurs ont une et une seule base, et
une fois connectés ils ne travaillent que dans cette base, alors oui
pourquoi pas créer plusieurs bases.




Dans quel cas peut on travailler simultanéement sur deux sociétés distinctes
?
C'est notre cas actuellement, mais parce que le problème a été mal posé
intialement.
Mon client a en fait deux établissements différents qui partagent par
exemple le fichier clients.

Mais attention plus de bases, plus d'administration, plus de sauvegardes
etc ...



Bien sûr, c'est le point négatif qui me fait hésiter.


pour nous par exemple, nous avons plus d'une 30taine de base mysql
réparties sur 4 serveurs (plus des bases localhost de tests) mais pour
chaque base, cela peut correspondre à plusieurs dossiers. Donc nous ne
créons de nouvelles bases que par ce que c'est un client différent. Mais à
l'intérieur de cette base, nous gérons tous les dossiers différents de ce
client (et qui n'ont là aussi rien à voir).
Et pour la multi connexions bases, nous mettons la liste des bases dispos
dans un .ini.(donc specifiques par clients)
A la connexion, un treeview qui montre les serveurs et les bases
associées, et la personne sélectionne sa base sur un serveur donné. (la
plupart n'ont qu'une base/serveur) et donc accède directement. On
sauvegarde dans un .ini aussi la derniere base/serveur utilisée ainsi que
le dossier sur lequel ils ont travaillés, et donc ils arrivent directement
avec leur derniere sélection.




Oui ce système à l'air très bien et je vais m'en inspirer si je choisis de
migrer vers un système multi-bases.
Mais il me reste cette question dont la réponse sera décisive: dans quel cas
peut on devoir accéder
simultanement à deux sociétés distinctes ?

Encore merci
I.G.LOG
Le #20429761
>
Pour schématiser il faut :
- un fichier dans l'arborescence commune avec la liste de tes sociétés.
- une base pour chaque société sur laquelle on est dirigé apres le choix.




Bonjour
Oui je comprends mais où se trouve ce fichier, de quel type... ?
Est ce une base séparée contenant une table des noms de sociétés et du nom
de la base associée ?
Merci
Gilles
Le #20430031
I.G.LOG a formulé la demande :

si tes utilisateurs sont sensés travailler sur toutes les sociétés, je ne
vois pas en quoi ton organisation actuelle pose problème ???



Bonjour,
Ca ne pose pas réellement de problème actuellement. Mais l'appli évolue en
permanence et je dois faire un choix !
J'ai de toute façon pu constater à quelle point l'option pointeur dans les
tables est lourde et génératrice de bugs, de complexité de programmation et
de maintenance.



Peux tu donner un cas concret de génération de bugs, de complexité??
C'est simplissime de faire ce genre de choses, j'avoue ne pas
comprendre ce qui te fait butter.

Les index sur le code société sont faits pour ça et c'est le principe d'une


Dans quel cas peut on travailler simultanéement sur deux sociétés distinctes
?
Mais il me reste cette question dont la réponse sera décisive: dans quel cas
peut on devoir accéder
simultanement à deux sociétés distinctes ?



C'est une question d'ordre purement fonctionnel, personne ne peut
répondre à ta place à cette question.

Une application peut nécessiter une base par client, comme le
contraire...

En tout cas, en matière de consolidation de données et d'analyse, il
n'y a pas pire que d'avoir N bases.

Mais encore une fois, c'est 100% dépendant de ton cahier des charges.
Il est donc vain de demander quelle est la meilleure solution sans
qu'on sache quel est ton besoin réel.

Quoi qu'il en soit, évite l'histoire du .ini
D'une part parce que les .ini, ca date de Windows 3 et moins...)
D'autre part, parce qu'il est peu judicieux de laisse un paramétrage de
ce type en local. Si tu as besoin de faire évoluer quoi que ce soit, ça
sera la galère.

Crée une base qui contiendra l'ensemble des droits et accès autorisés
par client, et ainsi, si tu dois ajouter ou retirer des droits, tu le
fera de manière centralisée, et pas dans 1230 .ini locaux!

La seule chose qui sera contenu dans un fichier de paramètre local
(stocké dans les dossiers users qui vont bien) (ou en base de registre)
c'est l'accès à cette base de données de paramétrage (et svp, crypte
les données, si je devais compter les "pro" qui mettent des
utilisateurs et mdp en clair dans des .ini, je n'aurais pas assez de ma
soirée (et au moins 1 fois sur 2, l'utilisateur a les droits totaux sur
la base, ce qui signifie que n'importe quel petit malin mal intentionné
peut tout dropper)...

Gilles.
tjfromparis
Le #20430861
bonjour

le principal avantage d'un eclatement de base sont les perfs
le principal probleme est la consolidation si tu en as a faire (ou les
mouvements inter-societes)

un truc qui marche du tonnerre sur oracle : le partitionnement des tables :
un seul fichier logique coupé en morceau sur plusieurs disques physiques

un truc sympa mais tres chaud à mettre en place : du RLS (sécurité ligne)
meme si un utilisateur fait un "select * ...." il ne verra que les données
auxquelles il a access. ca reduit considerablement le volume de données
visible par un utilisateur (par contre, sans precaution ca peut aussi
exploser les perfs des requetes)



"I.G.LOG" 4ae5ec31$0$971$

"Goof" 4ae57078$0$949$
Bonjour

Que ca soit en HF classique ou C/S.
l'option d'avoir une base donnée pour l'authentification et une base par
société s'impose relativement rapidement .
nous n'utilisons pas Mysql mais en HF C/S, nous utilisons une base pour
la gestion des utilisateurs/logs/gestion des droits et liste des société.
Après le login, on charge une base spécifique a la société en cours.
Et ca marche trés bien.
Pour changer de société, il suffit de changer la connexion Mysql des
fichiers de la société et c'est terminé.

Il est vrais que les interactions entre 2 société ne sont pas des plus
simple quand tout est cloisonné ainsi.
Mais la souplesse de maintenance et le fait d'être uniquement sur la
société en cours, est un vrai avantage dans 99.9% du code.

dans le systéme mono base,une erreur de manipulation/un crash disque ou
tout autre problème impacte toutes les sociétés.
Si une opération de maintenance doit être faite sur une société, on
bloque quand même les autre sociétés qui n'ont PE pas de problèmes.




Merci pour cette réponse qui montre les avantages d'un système multi-base,
et auxquels je n'avait pas pensé. Je voyais surtout la difficulté de
porgrammation et de structure des tables, dans lesquelle doivent
invariablement exister un pointeur société: très (trop) lourd et donc
synonyme de bugs ; je vais probablement m'orienture sur cette voie,
mais... quelles peuvent être les "interactions" entre deux sociétés
distinctes ?
Encore merci



Dc
Le #20431491
Bjr,

I.G.LOG a formulé ce lundi :
Bonjour
Oui je comprends mais où se trouve ce fichier, de quel type... ?
Est ce une base séparée contenant une table des noms de sociétés et du nom de
la base associée ?
Merci



ca peut etre de tout type. Et ca depend ce que tu dois mettre dedans.
Si faut juste choisr entre TOTO et DµUPOND , un fichier ini suffit.
S'il faut plus de renseignement, un fichier complet peut etre
necessaire.

a plus

--
-------------------------------------------------------------
www.ctc-soft.com
Gestion biblo-documentaire (free-share)
Comptabilité shareware
Logiciels de Gestion de saisie terrain
Spécialisé Tournées de boulangers
-------------------------------------------------------------
I.G.LOG
Le #20433401
>
Peux tu donner un cas concret de génération de bugs, de complexité??
C'est simplissime de faire ce genre de choses, j'avoue ne pas comprendre
ce qui te fait butter.




J'ai actuellement 60 tables. Pour que les données soient complètement
séparées, ca implique de retrouver le pointeur société sur chacune des
tables (les 60)
Comme je le disais,
Chaque requete doit prendre en compte le pointeur, c'est ce qui est
générateur de bug !!
Dans mon cas (rare j'en suis conscient), je dois transformer une société en
établissement d'une autre société: ca implique que je modifie tous les
pointeurs de chaque table !!


En tout cas, en matière de consolidation de données et d'analyse, il n'y a
pas pire que d'avoir N bases.




Que veut dire "consolidation" ?

Quoi qu'il en soit, évite l'histoire du .ini
D'une part parce que les .ini, ca date de Windows 3 et moins...)
D'autre part, parce qu'il est peu judicieux de laisse un paramétrage de ce
type en local. Si tu as besoin de faire évoluer quoi que ce soit, ça sera
la galère.

Crée une base qui contiendra l'ensemble des droits et accès autorisés par
client, et ainsi, si tu dois ajouter ou retirer des droits, tu le fera de
manière centralisée, et pas dans 1230 .ini locaux!

La seule chose qui sera contenu dans un fichier de paramètre local (stocké
dans les dossiers users qui vont bien) (ou en base de registre) c'est
l'accès à cette base de données de paramétrage (et svp, crypte les
données, si je devais compter les "pro" qui mettent des utilisateurs et
mdp en clair dans des .ini, je n'aurais pas assez de ma soirée (et au
moins 1 fois sur 2, l'utilisateur a les droits totaux sur la base, ce qui
signifie que n'importe quel petit malin mal intentionné peut tout
dropper)...

Gilles.




Merci pour tous ces conseils
Publicité
Poster une réponse
Anonyme