Architecture de BDD

Version imprimable

19/05/2007, 09h48
Romers

Architecture de BDD

Nous souhaitons mettre en place une base de données SQL SERVER 2005 commune de référence ainsi que N bases de données clientes. Par contre, les tables des bases de données Clientes sont en relation avec celle de la base commune.
Est ce possible?

Le but est de mettre la base commune (qui contient des données de référence) sur un serveur séparé car elle sera stable au niveau taille. Les bases de données clientes pourront être n'importe où voire même distantes.

il est indispensable de garder certaines relations entre les tables des bases de données pour l'intégrité des données.

Si ce n'est pas possible, est-il possible de contourner le pb?
Merci
19/05/2007, 13h21
ylarvor

je n'ai pas de réponse.

Il est possible de faire référence à une table extérieur à une base de données dans une requête ( ex: SELECT * FROM Database.dbo.Table ).

Par conséquent, je suppose que l'on puisse créer un trigger entre deux bases de données.

Mais une relation entre deux tables appartenant à deux bases de données différentes, cela me parait chaud... il faudrait tester.
20/05/2007, 19h42
Romers

C'est bien ce qu'il me semblait.
je vais creuser quand même.
Merci.
20/05/2007, 20h08
ylarvor

solution.

j'aimerais bien avoir des nouvelles de votre expérimentation.
22/05/2007, 09h40
Romers

Résultats test

Suite à quelques tests, une clé étrangère vers un champs d'une table d'une autre base de données n'est pas possible.

Sql Server erreur:
Les références de clés étrangères aux bases de données croisées ne sont pas prises en charge. Clé étrangère 'maBase.dbo.maTable'.

Dans les procédures stockées, c'est possible de faire référence à une autre base de donnée.
On peut aussi passer par une vue qui rappatrie des données de la base DB1 vers une vue contenue dans la base DB2. On peut ensuite faire des requêtes sur la vue mais toujours pas de contrainte possible avec les vues (logique!).

Par contre, je ne comprends pas bien le principe de Cross Database.
Si qqu'un peut m'éclairer.
22/05/2007, 09h50
Romers

Architecture bis

J'ai maintenant une autre question:
Supposons qu'on ait une appli qui se connecte à une base de données. Cette appli est distribuée chez des clients. Prenons le cas assez conséquent de 1000 clients.
Vaut-il mieux créer une BDD (dans la même instance) par client (1), ou mettre en commun les données de tous les clients dans une même base (2).

(1) avantage : pour la maintenance d'un client en particulier
Inconvénient : 1000 clients => 1000 BDD n'est ce pas trop lourd?

(2) avantage : mise à jour sur une base unique (pour le (1), on peut générer des scripts lancés par l'appli qui viennent mettre à jour la BDD correspondante.)
inconvénient : si une erreur apparaît dans un index par exemple, les 1000 clients sont bloqués.

Que choisir?

Merci.
22/05/2007, 10h29
ylarvor

sql serveur & 1000 bases de données.

Je ne pense pas que le serveur soit etudie pour contenir 1000 bases de données, meme petite. Par contre, il est etudie pour une grosse base de 1000 clients.
22/05/2007, 10h39
bibi_forever

Salut,

Pour ma part je suis entrain de creer un trigger qui met a jour une table en fonction d'une autre table située dans une autre base de donnée et ca fonctionne. Donc c'est possible avec des triggers!
De plus mes bases de données sont situées sur deux serveurs ms server différents.
22/05/2007, 10h42
Romers

Citation:

Envoyé par ylarvor

Je ne pense pas que le serveur soit etudie pour contenir 1000 bases de données, meme petite. Par contre, il est etudie pour une grosse base de 1000 clients.

d'après :
http://msdn2.microsoft.com/en-us/library/ms143432.aspx
On peut mettre 32767 bases dans une instance.

Mon soucis est davantage sur les bonnes pratiques et une architecture correcte. Parce que dans les 2 cas, ça marche mais la phylosophie n'est pas la même. Par contre, je n'ai pas de recul sur quelle façon de faire est la mieux.
22/05/2007, 10h46
Romers

Citation:

Envoyé par bibi_forever

Salut,

Pour ma part je suis entrain de creer un trigger qui met a jour une table en fonction d'une autre table située dans une autre base de donnée et ca fonctionne. Donc c'est possible avec des triggers!
De plus mes bases de données sont situées sur deux serveurs ms server différents.

Oui, ça marche mais mon premier problème de fond était sur de l'intégrite référentielle (foreign key) entre tables de différentes bases.
La question pouvait paraître évidente mais on ne sait jamais.
Maintenant, je sais que ce n'est pas possible.

Merci.
22/05/2007, 11h18
SQLpro

Citation:

Vaut-il mieux créer une BDD (dans la même instance) par client (1), ou mettre en commun les données de tous les clients dans une même base (2).

(1) avantage : pour la maintenance d'un client en particulier
Inconvénient : 1000 clients => 1000 BDD n'est ce pas trop lourd?

Absurde :
a) chaque base contient des tables systèmes qui contienne la définition des tables, des colonnes, des procédures,des fonctions... Vous allez donc encombrer le disque et la RAM de choses identiques et redondantes.
b) lorsque vous allez devoir modifier une table, une procédure une fonctio, il faudra donc mettre à jour 1000 bases !
je vous souhaite bien du courage et un bon investissement dans l'humain !

Citation:

2) avantage : mise à jour sur une base unique (pour le (1), on peut générer des scripts lancés par l'appli qui viennent mettre à jour la BDD correspondante.)

Evident : ce n'est pas la taille de la base qui a son importance mais le volume des données traitées...

Citation:

inconvénient : si une erreur apparaît dans un index par exemple, les 1000 clients sont bloqués.

de quelle erreur parlez vous ? Je n'ai pas connaissance de l'existance d'erreurs d'index !!!

A +
22/05/2007, 11h45
Romers

Ca conforte mon idée de départ.
Il y a des concepts qui ne me sont pas venus à l'esprit (Taille en RAM, etc...).

Pour l'erreur d'index, c'était un exemple. Je voulais parler d'erreur en général. Un fichier corrompu n'arrive pas qu'aux autres! Après, c'est une question de maintenance et d'administration, certe.

En tout cas, merci de votre réponse.