Discussion :

[Kropernic]

Bonjour,

Aujourd'hui, une question sur les schémas.

Développant uniquement pour usage interne à l'entreprise, jusqu'ici, nous avons presque toujours travaillé en utilisant une base de données par application.

Etant donné que certaines infos sont quand même toujours les mêmes comme par exemple les magasins et leurs informations associées, j'avais songé il y a déjà quelques temps (2 ans) à tout rassemble dans une seule et même base de données en compartimentant le tout via les schémas. En plus, cela aurait permis de créer certaines liaisons entre différentes tables jusque là impossible car dans des DB différentes.

Cette période coïncidait avec une formation basique sur sql server et le formateur m'avait déconseillé de séparer en schéma.

A l'époque, n'y connaissant quasi rien, je n'ai pas cherché plus loin et j'ai fait le mouton. Aujourd'hui, j'aimerais comprendre.

Si les schémas ont été inventés, c'est qu'ils doivent servir à quelque chose ^^.

Quelles sont les bonnes pratiques en la matière ?

Merci d'avance.

[dbaffaleuf]

Multi-Tenant Data Architecture: http://msdn.microsoft.com/en-us/library/aa479086.aspx

Du strict point de vue de la récupération de donnée:
- Doit-il y avoir une cohérence transactionnelle entre un magasin MAG1 et un magasin MAG2 ? En d'autres termes peut-il y avoir une même transaction qui modifie à la fois des objets de MAG1 et de MAG2 ? Auquel cas il est plus simple d'avoir une seule base et d'utiliser des schémas MAG1 et MAG2.
- Doit-on pouvoir restaurer les données de MAG1 sans impacter les données des autres magasins ? Si oui alors soit on garde des bases séparées, soit on place les schémas dans des filegroups différents. Cela permet de ne restaurer que le filegroup (et donc le schéma) endommagé. En Enterprise Edition, on peut même le faire base ouverte avec les autres filegroups ONLINE. (http://msdn.microsoft.com/en-us/library/ms177425.aspx)

[Kropernic]

je n'ai pas tout compris...

A mon avis, je n'ai pas été assez clair. Quand je parle des infos associées aux magasins, il s'agit juste de leur nom et numéro identifiant .
Et j'avais pris cela en exemple car dans beaucoup des DB, il y a toujours cette même table listant les magasins qui revient. Avec une seule grande DB, il n'y aurait plus qu'une seule et le jour où un magasin disparait ou se rajoute, la modif n'est à faire qu'à un seul endroit.

Concernant votre réponse :
J'irai lire l'article portant sur Multi-Tenant Data Architecture qui ne pourra être qu'instructif.

Ensuite concernant vos 2 points...
1 : J'essaie de me représenter des situations concrètes mais je crois que cela n'arrive jamais. Les magasins sont utilisés pour savoir où a été fait une vente ou dans quel magasin travail l'employé X par exemple.

2 : J'avoue ne pas suivre mais p-e que cela n'a plus de sens avec le complément d'informations que je viens d'apporter.

Désolé de la perte de temps de ne pas avoir été suffisamment clair du premier coup.

[dbaffaleuf]

Il faut faire le bilan des avantages / inconvénients de chaque solution, la solution avec les données isolées et la solution avec les données rassemblées, à la fois en termes de flexibilité (pouvoir relier des objets par des contraintes de clé étrangère par exemple), et en termes de possibilité de récupération. J'ai vu des cas où on mettait tout dans la même base parce que c'était plus pratique jusqu'au jour où suite à une suppression accidentelle de données d'un schéma isolé, il fallait remonter la base en entier et perdre toutes les modifications apportées aux autres schémas.

[Kropernic]

Ah ouais bien vu ça !

C'est vrai que les backups se font par DB et pas par schéma.

Y a-t-il des règles/conventions à ce sujet ?

[SQLpro]

Ah ouais bien vu ça !

C'est vrai que les backups se font par DB et pas par schéma.

Y a-t-il des règles/conventions à ce sujet ?

bémol : si vous associez les objets d'un schéma à un filegroup, vous pouvez sauvegarder par groupe de fichiers A CONDITION qu'aucune IR figurent entre deux schémas.

De toute façon dans votre cas vu que les données de vos bases s'interpénètrent il me semble qu'une seule base devrait être la règle, ne serait ce que pour la synchro de la sauvegarde

A +

[Kropernic]

Ce serait pas mal que j'arrive à faire débloquer un budget pour que vous veniez faire un audit par chez nous.

On en apprendrait beaucoup à mon avis. Mais mieux vaut que vous ne soyez pas cardiaque^^.

Quels sont vos tarifs au fait ? J'ai vu sur votre site que vous interveniez à Bruxelles mais je n'ai vu de tarif nulle part si ma mémoire est bonne.