Discussion :

[nieufhopla]

Bonjour,

Ma première question ici, est sans doute une question de débutant, mais je n'y ai pas encore trouvé réponse. Il s'agit plus d'une question d'architecture générale, mais je ne vois pas ou la poster et comme je travaille sur du SQLServer c'est sans doute le meilleur endroit.

Quels critères pour choisir d'avoir une ou plusieurs bases de données ? (sécurité, volumétrie, redondances des données, maintenance ...).
Attention, je ne cherche pas des réponses dans un cas particulier précis, mais à avoir vos points de vue sur la question d'une manière générale. Quels arguments en faveur d'un choix ou d'un autre etc.

Je m'explique, j'ai plusieurs applications utilisant des bases de données. Certaines applications très similaires mais ayant chacune leur propre base. Je reprends un système existant et vais le faire évoluer en y ajoutant de nouvelles applications. Ce serait sans doute le bon moment pour remettre a plat pas mal de choses d'ou ma question... une nouvelle base pour une nouvelle application ? Faire un travail de migration des anciennes applications pour consolider une seule base ? Rester sur l'existant ?

D'un côté, une seule base permettrait de factoriser les informations redondantes d'une application à l'autre, d'éviter les saisies multiples etc. bref du pont de vue de la pertinence et de l'exploitation des données ce serait mieux. Même si cela demande sans doute plus de travail de conception/normalisation pour minimiser les problèmes.

D'un autre côté, une seule base a sans doutes des inconvénients non ? Admettons que les volumes de données soient énormes ... les opérations de sauvegarde, de maintenance, les logs etc le seront également. Donc autre question, le volume de données (et d'entrées/sorties) est il à prendre en compte et à partir de quelle volumétrie doit on en prendre compte ?

Quels autres critères faut il analyser pour se prononcer en faveur d'une seule base ? D'une base par application, ou d'un autre découpage par fonction par exemple ou autre ?

Merci d'avance aux experts pour leurs lumières.

Et désolé si je ne post pas au bon endroit, mais je n'ai pas vu de rubrique pour une question aussi générale.

[SQLpro]

Si fonctionnellement les bases sont indépendantes, alors vous devez faire plusieurs bases.
Si les bases sont fonctionnellement dépendantes, alors mieux vaut ne faire qu'une seule base. En effet ceci mutualisera le référentiel de données et évitera donc la redondance et pire la désynchronisation des informations lié à la redondance (deux informations différentes alors que la même est attendue).
Les problématique secondaires - volumétrie, indépendances logiques, sauvegardes à périodicité distinctes, sécurité... - se règlent soit au niveau logique, soit au niveau physique à l'aide de :
1) les espaces de stockage physiques (FILEGROUP, FILE, PARTITION...)
2) l'organisation des disques physiques (niveau de RAID, conception des LUN sur les SAN...)
3) les espaces de stockage logique (SCHEMA SQL)
4) une certaine rigueur dans l'administration et la gestion de la sécurité.

A lire sur les aspects physique du stockage : http://blog.developpez.com/sqlpro/p8...t-le-stocakge/
A lire sur l'utilité des schéma SQL : http://blog.developpez.com/sqlpro/p5...es-schema-sql/

Votre post est tout à fait légitime ici !

A +

[dbaffaleuf]

Quels autres critères faut il analyser pour se prononcer en faveur d'une seule base ?

La consistance de la sauvegarde par exemple: comment fais-tu pour restaurer 10 bases de données à un même état consistant dans le temps ? Il y a des outils pour séparer logiquement ou physiquement des données dans une même base (schémas, partitions,multiples groupes de fichiers). Tu as raison cependant, il y a un gros travail d'étude en amont si tu pars de ce côté là.

David B.

[Fabien Celaia]

On parle ici de mutualisation. Soyons donc clair sur les termes.

Vous souhaitez mutualiser des instances ou des bases de données ?

La mutualisation de base n'apporte pas grand chose, si ce n'est de la complexité ... et un risque majeur si tous les composants de la base n'évoluent pas en même temps.

La mutualisation d'instances est possible, et bien plus simple sous MS-SQL que, par exemple, sous Oracle. Il y a en effet relativement peu de porosité entre les bases de données, surtout avec les dernières versions de MS-SQL (je pense principalement au gestionnaire de ressources permettant d'éviter qu'une application ne vampirise toutes les ressources d'une instance).

Elle a certains avantages
- baisse du coût des licences (pour microsoft, ainsi que pour tous les outils périphériques (ex. backups, bandes,... )
- baisse du coût matériel (bien qu'il faille alors se diriger vers un serveur un peu plus musclé)
- baisse de la charge d'administration
- aisance à s'orienter vers des solutions de haute dispo
- etc...

Et elle a certaines contraintes
- l'instance mutualisée n'aura qu'un seul type de paramètres systèmes (il vaut donc mieux éviter de mélanger de l BI avec de l'OLTP)
- l'arrêt de l'instance paralysera toutes les applications (d'où l'intérêt d'une solution à haute dispo)
- versionning : si vous migrez vers une version ultérieur, la migration devra se faire en bloc pour toutes vos bases.
- etc

Ceci étant dit, votre choix n'est pas inscrit dans le marbre : en tout temps, si vous maîtrisez les datasources de chacune de vos applications, il vous sera possible de redéplacer une base qui poserait problème.

[SQLpro]

Et elle a certaines contraintes
- l'instance mutualisée n'aura qu'un seul type de paramètres systèmes (il vaut donc mieux éviter de mélanger de l BI avec de l'OLTP)
- l'arrêt de l'instance paralysera toutes les applications (d'où l'intérêt d'une solution à haute dispo)
- versionning : si vous migrez vers une version ultérieur, la migration devra se faire en bloc pour toutes vos bases.

1) l'instance mutualisée n'aura qu'un seul type de paramètres systèmes à modérer avec l'apparition du gouverneur de ressources.
2) l'arrêt de l'instance paralysera toutes les applications Comme tu l'as dit les solution de haute dispo comme mirroring, clustering, log shipping ou encore capture d'IO (genre double take) font que ceci est peu important
3) versionning : c'est le seul véritable problème !

A +

[nieufhopla]

Wouhhh ça dépote, merci pour ces réponses si rapides.

Ok pour la question de monté de version... bon ce n'est pas non plus quelque chose que l'on fait tous les jours, et cela se prépare sur des serveurs de pré-production à l'avance.

Mon interrogation reste au niveau de la sécurité sur le fait d'avoir une seule base. Le risque se porte sur toutes les applications. Il sera toujours plus simple de corrompre un base que N...



Merci également pour les liens forts instructifs !

[SQLpro]

si la sécurité vous préoccupe, suivez ce cours : http://www.orsys.fr/formation-sql-se...5-securite.asp

A +