Bonjour,
Par exemple, comment remplir une combo-box avec le nom des sociétés et le nom
de la base concernée ?
Bonjour,
Par exemple, comment remplir une combo-box avec le nom des sociétés et le nom
de la base concernée ?
Bonjour,
Par exemple, comment remplir une combo-box avec le nom des sociétés et le nom
de la base concernée ?
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
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
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
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.
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.
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.
>
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.
>
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.
>
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.
>
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.
>
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.
>
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.
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
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 ?
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
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 ?
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
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 ?
"Goof" a écrit dans le message de news:
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
"Goof" <goof@altern.org> a écrit dans le message de news:
4ae57078$0$949$ba4acef3@news.orange.fr...
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
"Goof" a écrit dans le message de news:
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
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
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
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
>
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.
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.
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.
>
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.
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.
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.
>
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.
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.
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.