Discussion :

[rvzip64]

Salut tout le monde,

Actuellement je dispose d'une base de données de 240 tables qui fait 20 Go sur mon serveur.
Je me pose la question si ce n'est pas mieux de faire plusieurs bases, sachant que souvent j'ai un ensemble de 15 tables qui ont un lien entre elles, mais pas de lien avec le reste des autres tables.

Qu'en pensez-vous ?

Qu'elles sont les règles ?

[CinePhil]

une base de données de 240 tables

15 tables qui ont un lien entre elles, mais pas de lien avec le reste des autres tables.

Y'aurait pas comme un problème de modélisation par hasard ?

On pourrait avoir le schéma des 15 tables liées entre elles et de quelques autres tables isolées ?

[rvzip64]

Y a clairement un problème de modélisation !
C'est pour ça que je me demande si c'est pas mieux de faire des schémas différents

[CinePhil]

Commence par refaire une modélisation correcte, au besoin en séparant les domaines que couvrent la base de données, qui à les relier ensuite.

Mais on ne pourra pas t'aider si tu n'en dis pas davantage.

Et pour les questions sur la modélisation, c'est par là.
A moins que tu ne préfères UML ?

[Vlade]

La base de donnée est déjà en production et à 20Go
L'UML ne peut rien apporter dans ce cas car en rédéfinnisssant l'architecture via une approche objet les données de la base seront perdues.

Par contre il serait élégant de modéliser une extension UML en rajoutant des contraintes ce qui permettrait en fonction des réquêtes d'orientéer celle-ci dans la base de 20Go ou autre part. Dans ce cas l'utilisation d'une autre base semble être la plus sage décision.
Mon conseil: Si la base marche bien et que les réquêtes sont déjà là, il faut rien changer à l'existant sinon on va au devant de gros soucis. Soit on change tout soit on change rien !!!
Par contre étendre la base de donnée en la visualisant dans un diagramme UML avant de la mapper vers une autre base en tulisant les annotations java et hibernate ou EJB 3 est une belle approche. Il faut rajouter des contraintes directement dans le modèle UML qui a été reversé depuis la base de donnée et codé la méthode dans les nouvelles classes. Mettre des contraintes en amont serait élégant, pas trop couteux en temps et assez efficace.

[CinePhil]

La base de donnée est déjà en production et à 20Go

Il nous dit que sa base fait 20 Go, pas qu'elle est en production. C'est possible mais pas sûr. Il peut avoir récupéré des données d'ailleurs et est en train de les architecturer dans une base de données. C'est à lui de nous le dire.

L'UML ne peut rien apporter dans ce cas car en rédéfinnisssant l'architecture via une approche objet les données de la base seront perdues.

UML est un langage de modélisation et n'a pas le pouvoir de détruire des données.
Il peut très bien modéliser ses données à l'aide un diagramme de classes, implanter ce modèle dans une nouvelle base de données, y importer ensuite ses données méthodiquement.
Et il peut bien sûr faire le même travail de conception à l'aide d'un modèle conceptuel de traitement (MCD) de la méthode Merise.

Par contre il serait élégant de modéliser une extension UML en rajoutant des contraintes ce qui permettrait en fonction des réquêtes d'orientéer celle-ci dans la base de 20Go ou autre part. Dans ce cas l'utilisation d'une autre base semble être la plus sage décision.

Une extension à une base mal conçue, ça peut être un sparadrap sur une fracture interne !

A la lecture de son message, j'ai plutôt l'impression qu'il est dans une phase de conception ou de reconception que dans une phase d'extension. A lui de nous le dire avant de l'orienter vers une solution.
Sans une expression plus claire de son besoin et un aperçu de l'existant, je ne me risquerais pas à lui donner un conseil aussi affirmé que tu le fais.

[rvzip64]

Merci tout le monde pour vos réponses.
Je vous donne un peu plus de détail sur mon problème.

La base de données est bien en production.

Plusieurs parties de cette base sont en cours d'amélioration (autant dire refaites en entier), c'est pour cela que je me pose la question de suivre la "régle" qui est déjà en place de tout mettre dans la meme base , ou s'il est temps de faire plusieurs bases.

Si je devais refaire toutes la base de données (ce qui n'est pas le cas), je me retrouverais avec facilement 19 bases

[CinePhil]

19 bases sur un serveur, ça fait beaucoup parce que le SGBD réserve de l'espace et utilise des ressources pour chaque base.

D'une manière générale, il vaut mieux ne faire qu'une seule base. Mais à condition que celle-ci couvre un domaine bien délimité et qu'il n'y ait pas trop de morceaux séparés, comme cela semble être le cas. Mais comme tu ne nous as toujours pas dit pourquoi tu n'as que 15 tables en relations et les 225 autres isolées, nous ne pouvons toujours pas nous prononcer sur la meilleure architecture à envisager.

[Vlade]

Tu as raison Cinephil car j'ai toujours une vue édition de logiciel et ce travail est du ressort du consultant
Donc attention avant de valider une approche, il faut appeler un expert consultant extérieur si on maitrise pas tout !!

[rvzip64]

Mais comme tu ne nous as toujours pas dit pourquoi tu n'as que 15 tables en relations et les 225 autres isolées, nous ne pouvons toujours pas nous prononcer sur la meilleure architecture à envisager.

Non je n'ai pas voulu dire ça, j'ai dit que en gros dans ces 240 tables , les tables marchaient par groupes de 15 (environ).

Aprés j'ai deja 25 bases sur mon serveur (c'est pas un pc grand public, c'est un server avec SAN et tout ce qui va avec).

[CinePhil]

Si les tables marchent par groupe de 15, cela veut-il dire que ces groupes concernent des domaines indépendants les uns des autres ?
Si oui, alors tu peux faire des bases différentes.
Si ce sont plutôt des sous-domaines d'un domaine plus général et que ces groupes sont interrogés par la ou les mêmes applications, alors je garderais plutôt une seule base.

Encore une fois, difficile de conseiller une approche sans en savoir plus de quoi il retourne. Est-ce une gestion globale d'entreprise ? Un ensemble de sites web indépendants les uns des autres ?...

[rvzip64]

En gros les 15 tables représentes la gestion d'une machine de production.
Donc chaque machine est indépendante dans sont fonctionnement et tout est regroupé dans une base de données "Machine"

[CinePhil]

Si les 15 tables sont grosso-modo identiques pour chaque machine,, c'est qu'il y a effectivement un gros problème de modélisation !
On peut très bien gérer un parc de machines avec une seule base mais pas avec un groupe de tables pour chaque machine.
Pas étonnant qu'il y ait 240 tables et 20 Go !

Si tu nous donnes le schéma de deux groupes, on peut t'aider à optimiser tout ça !
La partie que tu refais sera nickel et tu n'auras quasiment rien d'autre à faire quand les autres groupes devront migrer à leur tour.
C'est la force des SGBD : qu'on gère 1 machine ou 50, c'est en principe la même structure de données, éventuellement à quelques spécialisations près pour certaines machines et qui se gèrent avec quelques tables supplémentaires sans toucher à la structure globale.

[rvzip64]

Non non non ...

On s'est mal compris.
Les machines ne sont pas identiques, elles sont différentes et ne marche pas de la meme façon !
Les tables ne se ressemblent pas !
Et les parties qui sont factorisables sont regroupées dans des dbs spécifiques.

J'ai bien des tables différentes.