Je suis confronté à un petit problème au niveau de mon analyse :
Je dois développer une application qui gère plusieurs sociétés.
Pour cela je crée autant de base de données qu'il y a de sociétés
(Société1, Société2,...etc) et une base de données commune (Commun).
Dans la base de données "Commun" j'ai toutes les tables communes au
base de données :
Les clients
Les fournisseurs
Dans chaque base de données "SociétéX" je crée les mêmes tables :
- factures
- réglements
- commandes
Ma question est la suivante :
Si je me mets dans cette configuration est-il possible de faire des
requêtes sur des tables se trouvant dans différentes bases de données ?
Un collègue pense qu'on devrait créer une seule base de données avec
une table qui s'appelle Société, et dans chaque table (Facture,
Réglement,...etc) ajouter une colonne IdSociété qui contient
l'identifiant de la société à qui appartient la facture...
Le seul problème c'est qu'il faut propager l'identifiant partout dans
l'application et penser à ajouter partout l'égalité "WHERE
LaTable.IdSociété = IdSociété
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick Mevzek
Le Sun, 25 Jun 2006 20:39:07 +0200, Gilles TOURREAU a écrit :
Ma question est la suivante : Si je me mets dans cette configuration est-il possible de faire des requêtes sur des tables se trouvant dans différentes bases de données ?
Cela dépend du SGBDR. Plutôt non, en général.
Mais, a priori, une base doit être un ensemble clos.
Dans votre cas de figure, à part si les clients et fournisseurs sont les mêmes pour toutes les sociétés, ce qui est peu probable, votre base «commun» n'a pas beaucoup de sens.
Un collègue pense qu'on devrait créer une seule base de données avec une table qui s'appelle Société, et dans chaque table (Facture, Réglement,...etc) ajouter une colonne IdSociété qui contient l'identifiant de la société à qui appartient la facture... Le seul problème c'est qu'il faut propager l'identifiant partout dans l'application et penser à ajouter partout l'égalité "WHERE LaTable.IdSociété = IdSociété
Voir 1) les espaces de nom ou schémas 2) les vues qui sont deux pistes qui peuvent vous aider.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/index>
Le Sun, 25 Jun 2006 20:39:07 +0200, Gilles TOURREAU a écrit :
Ma question est la suivante :
Si je me mets dans cette configuration est-il possible de faire des
requêtes sur des tables se trouvant dans différentes bases de données ?
Cela dépend du SGBDR. Plutôt non, en général.
Mais, a priori, une base doit être un ensemble clos.
Dans votre cas de figure, à part si les clients et fournisseurs sont les
mêmes pour toutes les sociétés, ce qui est peu probable, votre base
«commun» n'a pas beaucoup de sens.
Un collègue pense qu'on devrait créer une seule base de données avec
une table qui s'appelle Société, et dans chaque table (Facture,
Réglement,...etc) ajouter une colonne IdSociété qui contient
l'identifiant de la société à qui appartient la facture...
Le seul problème c'est qu'il faut propager l'identifiant partout dans
l'application et penser à ajouter partout l'égalité "WHERE
LaTable.IdSociété = IdSociété
Voir
1) les espaces de nom ou schémas
2) les vues
qui sont deux pistes qui peuvent vous aider.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/index>
Le Sun, 25 Jun 2006 20:39:07 +0200, Gilles TOURREAU a écrit :
Ma question est la suivante : Si je me mets dans cette configuration est-il possible de faire des requêtes sur des tables se trouvant dans différentes bases de données ?
Cela dépend du SGBDR. Plutôt non, en général.
Mais, a priori, une base doit être un ensemble clos.
Dans votre cas de figure, à part si les clients et fournisseurs sont les mêmes pour toutes les sociétés, ce qui est peu probable, votre base «commun» n'a pas beaucoup de sens.
Un collègue pense qu'on devrait créer une seule base de données avec une table qui s'appelle Société, et dans chaque table (Facture, Réglement,...etc) ajouter une colonne IdSociété qui contient l'identifiant de la société à qui appartient la facture... Le seul problème c'est qu'il faut propager l'identifiant partout dans l'application et penser à ajouter partout l'égalité "WHERE LaTable.IdSociété = IdSociété
Voir 1) les espaces de nom ou schémas 2) les vues qui sont deux pistes qui peuvent vous aider.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/index>
William Marie
"Gilles TOURREAU" a écrit dans le message de news:
Bonjour tout le monde !
Je suis confronté à un petit problème au niveau de mon analyse :
Je dois développer une application qui gère plusieurs sociétés.
Pour cela je crée autant de base de données qu'il y a de sociétés (Société1, Société2,...etc) et une base de données commune (Commun).
Là, je tique !
De 2 choses l'une
- ou bien les sociétés n'ont rien à voir entre elles et il n'y a pas lieu de faire une base de donnée commune (comment la faire, d'ailleurs, les bases de données sont assez étanches). Si ce n'est qu'elles sont gérées pareillement auquel cas il suffit de copier toute la structure de la 1ere base de la première société une fois qu'on en est satisfait.
- ou bien elles ont des transactions possibles entre elles et des points communs. Auquel cas il ne faut qu'une base de données, une table sociétés, et des références à chaque société chaque fois que c'est nécessaire (dans les tables factures, clients, fournisseurs, par exemple).
Bien sûr ce n'est qu'un canevas d'ordre général, il faut avoir mis vraiment le nez dans le problème pour être plus catégorique. -- ========================================================== William Marie Toulouse (France) mailto: ATTENTION ! Anti-SPAM pour m'écrire remplacer trapellun.net par free.fr http://wmarie.free.fr ===========================================================
"Gilles TOURREAU" <gilles.tourreau@pos.fr> a écrit dans le message de
news: mn.ccd77d66f4b71bf4.52180@pos.fr...
Bonjour tout le monde !
Je suis confronté à un petit problème au niveau de mon analyse :
Je dois développer une application qui gère plusieurs sociétés.
Pour cela je crée autant de base de données qu'il y a de sociétés
(Société1, Société2,...etc) et une base de données commune (Commun).
Là, je tique !
De 2 choses l'une
- ou bien les sociétés n'ont rien à voir entre elles et il n'y a pas
lieu de faire une base de donnée commune (comment la faire,
d'ailleurs, les bases de données sont assez étanches). Si ce n'est
qu'elles sont gérées pareillement auquel cas il suffit de copier toute
la structure de la 1ere base de la première société une fois qu'on en
est satisfait.
- ou bien elles ont des transactions possibles entre elles et des
points communs. Auquel cas il ne faut qu'une base de données, une
table sociétés, et des références à chaque société chaque fois que
c'est nécessaire (dans les tables factures, clients, fournisseurs, par
exemple).
Bien sûr ce n'est qu'un canevas d'ordre général, il faut avoir mis
vraiment le nez dans le problème pour être plus catégorique.
--
========================================================== William Marie
Toulouse (France)
mailto:wmarie@trapellun.net
ATTENTION ! Anti-SPAM pour m'écrire remplacer trapellun.net
par free.fr
http://wmarie.free.fr
===========================================================
"Gilles TOURREAU" a écrit dans le message de news:
Bonjour tout le monde !
Je suis confronté à un petit problème au niveau de mon analyse :
Je dois développer une application qui gère plusieurs sociétés.
Pour cela je crée autant de base de données qu'il y a de sociétés (Société1, Société2,...etc) et une base de données commune (Commun).
Là, je tique !
De 2 choses l'une
- ou bien les sociétés n'ont rien à voir entre elles et il n'y a pas lieu de faire une base de donnée commune (comment la faire, d'ailleurs, les bases de données sont assez étanches). Si ce n'est qu'elles sont gérées pareillement auquel cas il suffit de copier toute la structure de la 1ere base de la première société une fois qu'on en est satisfait.
- ou bien elles ont des transactions possibles entre elles et des points communs. Auquel cas il ne faut qu'une base de données, une table sociétés, et des références à chaque société chaque fois que c'est nécessaire (dans les tables factures, clients, fournisseurs, par exemple).
Bien sûr ce n'est qu'un canevas d'ordre général, il faut avoir mis vraiment le nez dans le problème pour être plus catégorique. -- ========================================================== William Marie Toulouse (France) mailto: ATTENTION ! Anti-SPAM pour m'écrire remplacer trapellun.net par free.fr http://wmarie.free.fr ===========================================================
Jean-Marc Molina
Gilles TOURREAU wrote:
Je dois développer une application qui gère plusieurs sociétés.
Pour cela je crée autant de base de données qu'il y a de sociétés (Société1, Société2,...etc) et une base de données commune (Commun).
Si l'application est utilisée sous la forme d'un service par les sociétés, il vaut mieux éviter d'avoir plusieurs bases. Si l'application était déployée chez les sociétés alors là des bases différentes seraient justifiées, même architecture mais contenus différents.
Un collègue pense qu'on devrait créer une seule base de données avec une table qui s'appelle Société, et dans chaque table (Facture, Réglement,...etc) ajouter une colonne IdSociété qui contient l'identifiant de la société à qui appartient la facture... Le seul problème c'est qu'il faut propager l'identifiant partout dans l'application et penser à ajouter partout l'égalité "WHERE LaTable.IdSociété = IdSociété
Pensez vous que c'est la meilleure solution ?
Tout dépend du contexte mais le design à base de IdSociété me semble le plus logique. Une table des sociétés et des clés étrangères dans les autres.
Avez-vous d'autres idées ?
Utiliser une couche supplémentaire pour accéder aux données de la base (DAO, ORM...). Il n'est pas logique de dire « penser à ajouter partout l'égalité "WHERE LaTable.IdSociété = IdSociété » quand le design de la base change. L'implémentation ne devrait pas en dépendre autant. En adoptant une approche objet, ici il vous suffirait d'ajouter un champ "id_société" à une table de base dont toutes les autres hériteraients (sous PostgreSQL par exemple) et dans votre code de changer quelques méthodes de vos classes facture, réglement, commande... On peut aussi s'en sortir avec de simples SGBDR comme MySQL en propageant le champ id_société partout et en exploitant les fonctionnalités objets de son langage favori : PHP 5, Java...
Donc si vous hésitez entre les deux solutions, jouez la carte de la flexibilité pour éviter d'avoir à tout redévelopper de zéro... mais je crois plus en la seconde solution, celle de votre collègue, qu'en la première qui me semble moins évolutive et plus difficile à maintenir.
Gilles TOURREAU wrote:
Je dois développer une application qui gère plusieurs sociétés.
Pour cela je crée autant de base de données qu'il y a de sociétés
(Société1, Société2,...etc) et une base de données commune (Commun).
Si l'application est utilisée sous la forme d'un service par les sociétés,
il vaut mieux éviter d'avoir plusieurs bases. Si l'application était
déployée chez les sociétés alors là des bases différentes seraient
justifiées, même architecture mais contenus différents.
Un collègue pense qu'on devrait créer une seule base de données avec
une table qui s'appelle Société, et dans chaque table (Facture,
Réglement,...etc) ajouter une colonne IdSociété qui contient
l'identifiant de la société à qui appartient la facture...
Le seul problème c'est qu'il faut propager l'identifiant partout dans
l'application et penser à ajouter partout l'égalité "WHERE
LaTable.IdSociété = IdSociété
Pensez vous que c'est la meilleure solution ?
Tout dépend du contexte mais le design à base de IdSociété me semble le plus
logique. Une table des sociétés et des clés étrangères dans les autres.
Avez-vous d'autres idées ?
Utiliser une couche supplémentaire pour accéder aux données de la base (DAO,
ORM...). Il n'est pas logique de dire « penser à ajouter partout l'égalité
"WHERE LaTable.IdSociété = IdSociété » quand le design de la base change.
L'implémentation ne devrait pas en dépendre autant. En adoptant une approche
objet, ici il vous suffirait d'ajouter un champ "id_société" à une table de
base dont toutes les autres hériteraients (sous PostgreSQL par exemple) et
dans votre code de changer quelques méthodes de vos classes facture,
réglement, commande... On peut aussi s'en sortir avec de simples SGBDR comme
MySQL en propageant le champ id_société partout et en exploitant les
fonctionnalités objets de son langage favori : PHP 5, Java...
Donc si vous hésitez entre les deux solutions, jouez la carte de la
flexibilité pour éviter d'avoir à tout redévelopper de zéro... mais je crois
plus en la seconde solution, celle de votre collègue, qu'en la première qui
me semble moins évolutive et plus difficile à maintenir.
Je dois développer une application qui gère plusieurs sociétés.
Pour cela je crée autant de base de données qu'il y a de sociétés (Société1, Société2,...etc) et une base de données commune (Commun).
Si l'application est utilisée sous la forme d'un service par les sociétés, il vaut mieux éviter d'avoir plusieurs bases. Si l'application était déployée chez les sociétés alors là des bases différentes seraient justifiées, même architecture mais contenus différents.
Un collègue pense qu'on devrait créer une seule base de données avec une table qui s'appelle Société, et dans chaque table (Facture, Réglement,...etc) ajouter une colonne IdSociété qui contient l'identifiant de la société à qui appartient la facture... Le seul problème c'est qu'il faut propager l'identifiant partout dans l'application et penser à ajouter partout l'égalité "WHERE LaTable.IdSociété = IdSociété
Pensez vous que c'est la meilleure solution ?
Tout dépend du contexte mais le design à base de IdSociété me semble le plus logique. Une table des sociétés et des clés étrangères dans les autres.
Avez-vous d'autres idées ?
Utiliser une couche supplémentaire pour accéder aux données de la base (DAO, ORM...). Il n'est pas logique de dire « penser à ajouter partout l'égalité "WHERE LaTable.IdSociété = IdSociété » quand le design de la base change. L'implémentation ne devrait pas en dépendre autant. En adoptant une approche objet, ici il vous suffirait d'ajouter un champ "id_société" à une table de base dont toutes les autres hériteraients (sous PostgreSQL par exemple) et dans votre code de changer quelques méthodes de vos classes facture, réglement, commande... On peut aussi s'en sortir avec de simples SGBDR comme MySQL en propageant le champ id_société partout et en exploitant les fonctionnalités objets de son langage favori : PHP 5, Java...
Donc si vous hésitez entre les deux solutions, jouez la carte de la flexibilité pour éviter d'avoir à tout redévelopper de zéro... mais je crois plus en la seconde solution, celle de votre collègue, qu'en la première qui me semble moins évolutive et plus difficile à maintenir.
Jerome PAULIN
Bonjour,
Sous MySQL (pour les autres, je ne sais pas, et comme tu n'as rien précisé...), tu peux préfixer les noms de tables avec la base (a condition que les bases resident sur le meme serveur).
Exemple :
select champ1,...,champN from commun.table1 inner join societe1.table2 on commun.table1.id=societe1.table2.id
commun represente la base commune societe represente la base specifique a une societe
Cordialement,
gg
Bonjour,
Sous MySQL (pour les autres, je ne sais pas, et comme tu n'as rien
précisé...), tu peux préfixer les noms de tables avec la base (a
condition que les bases resident sur le meme serveur).
Exemple :
select
champ1,...,champN
from
commun.table1
inner join societe1.table2 on commun.table1.id=societe1.table2.id
commun represente la base commune
societe represente la base specifique a une societe
Sous MySQL (pour les autres, je ne sais pas, et comme tu n'as rien précisé...), tu peux préfixer les noms de tables avec la base (a condition que les bases resident sur le meme serveur).
Exemple :
select champ1,...,champN from commun.table1 inner join societe1.table2 on commun.table1.id=societe1.table2.id
commun represente la base commune societe represente la base specifique a une societe
