Discussion :

[repgarent]

Bonjour,

je suis dans une entreprise industrielle où les applications utilisé sont en train d'étre "modernisé" (en gros on passe du couple infernal excel/access a des appli asp.net).

Dans tout les sujet, il y a des données communes : liste de personne, de machine, etc... qui sont pour l'instant redondantes d'un fichier a l'autres, et donc peu fiable.
du coup je me pose la question de centraliser un peu tout ça, histoire de ne pas avoir dix fois les mêmes données dans mes base.

Pour faire ça, j'entrevois deux possibilités :
- une seule BDD pour toutes les appli. le plus facile a mettre en place, le problème étant que je n'ai aucune idée de combien d'appli ça représente... et a maintenir, je ne suis pas sur que ce soit l'idéal.
- une BDD pour les données redondantes, et une BDD par appli qui viendront se "brancher" dessus si besoin. plus facile a gérer sur le long terme je pense, mais je ne sais pas comment le mettre en place.

donc voilà ou j'en suis, des conseils?

[CinePhil]

Il peut y avoir une BDD contenant plusieurs schémas. C'est même la meilleure façon de faire.

Il faut cependant savoir que cette distinction entre schéma et BDD est plutôt floue chez MySQL. Sur un même serveur MySQL (ou MariaDB), on peut créer plusieurs bases de données et faire des requêtes sur plusieurs BDD en même temps. Ce qui rapproche en fait davantage la notion BDD de MySQL de la notion standard de schéma.
En effet, dans un autre SGBD (SQL Server, Oracle, Postgresql...), on peut créer plusieurs BDD qui peuvent avoir chacune plusieurs schémas. On peut faire des requêtes entre plusieurs schémas de la même BDD mais on ne peut pas faire de requêtes sur plusieurs BDD.

[aieeeuuuuu]

Bonjour,

Avec une BDD "centrale" et une BDD périphérique par application, vous ne pourrez pas déclarer de contraintes d'intégrité référentielle. et ça va vite être le bazard, quand l'appli A autorisera a supprimer des données référencées dans l'appli B...

Faites plutôt une seule base. Vous pouvez utiliser les schémas pour regrouper les objets par appli utilisatrice...

Avez-vous déjà fait le choix du SGBDR ?

[repgarent]

effectivement, les schémas semblent bien régler le problème, je vais me replonger dans les tutos!

Avez-vous déjà fait le choix du SGBDR ?

le choix est imposé par la boite, c'est SQL server 2012.

[CinePhil]

Alors les schémas, c'est vraiment la solution.

[vince.f]

Découplez au maximum vos applications, tout regrouper dans une seule BDD se paye souvent assez cher plusieurs années après. Vous n’avez pas précisé la taille des applications et le nombre d’utilisateurs, mais pour n’importe quoi un tant soit peu sérieux vous allez au-devant de gros casses tètes en terme de maintenance.

C’est assez commun de se retrouver prisonnier de la « BDD unique » de plusieurs centaines de Go que personne ne veut toucher parce qu’elle affecte toutes les applications de l’entreprise. A moins que vos applications soient minuscules (et que vous soyez sûr qu’elles vont le rester), je vous déconseille vivement de vous infliger ça.

PS : Faire des requêtes entre plusieurs BDD d’une même instance avec SQL Server est tout à fait possible contrairement à ce qui est dit plus haut.

[aieeeuuuuu]

Découplez au maximum vos applications, tout regrouper dans une seule BDD se paye souvent assez cher plusieurs années après. Vous n’avez pas précisé la taille des applications et le nombre d’utilisateurs, mais pour n’importe quoi un tant soit peu sérieux vous allez au-devant de gros casses tètes en terme de maintenance.

Quels genres de problèmes de maintenance ?

C’est assez commun de se retrouver prisonnier de la « BDD unique » de plusieurs centaines de Go que personne ne veut toucher parce qu’elle affecte toutes les applications de l’entreprise. A moins que vos applications soient minuscules (et que vous soyez sûr qu’elles vont le rester), je vous déconseille vivement de vous infliger ça.

Pensez-vous réellement qu'il est alors préférable d'avoir plusieurs dizaines de BDD différentes, pour une volumétrie au moins égale (il faut toujours stocker les mêmes données) voire supérieure (copie de données entre bases pour assurer ce fameux "découplage" et qui oblige en plus à avoir des système de synchronisation complexes et chronophage) ?

PS : Faire des requêtes entre plusieurs BDD d’une même instance avec SQL Server est tout à fait possible contrairement à ce qui est dit plus haut.

En effet !
Il faut toutefois garder à l'esprit qu'il reste impossible de définir des contraintes d'intégrité référentielle entre deux tables de deux bases différentes. Cela a deux conséquences majeures :
1/ soit vous assurez l'IR dans les applicatifs, et vous aurez fatalement des anomalies très rapidement (surtout si différentes applis accèdent indépendamment aux données), soit vous l'assurez par le biais de triggers, ce qui est préférable, mais bien plus couteux en dev et en temps machine qu'avec L'IR déclarative.
2/ l'absence des clefs étrangères dûment déclarées nuira aux performances, en privant l'optimiseur de précieuses informations.

[vince.f]

Personne ne vous parle de stocker les mêmes données dans différentes BDD, les données redondantes comme les clients ou les produits par exemple ont en général leur propre BDD avec un seul point d’entrée et de sortie et sont utilisées (par exemple via une API) par x nombre d’applications de façon consistante. Ces données la seront a priori utilisées pendant plusieurs décennies contrairement aux applications qui ont un cycle de vie beaucoup plus court.

Les données des applications elles-mêmes n’ont aucun intérêt à être couplées avec les données de l’entreprise (donc les fameux clients et produits). Si demain vous décidez qu’une de vos applications devient suffisamment critique pour nécessiter son propre server de BDD, vous faites quoi ? A priori pas grand-chose puisque tout a été conçu pour résider au même endroit et que quoi que vous fassiez, ça aura un impact sur d’autres applications qui n’ont en théorie rien à voir. Et cette situation est relativement courante, beaucoup d’entreprise se séparent peu à peu de ces BDD uniques monstrueuses qui coûtent plusieurs centaines de milliers d’euros par an en licences (les fameux cœurs que Microsoft facture).

Un exemple de problème de maintenance ? Restaurer une BDD qui affecte toutes les applications, installer des mises à jour etc. Le challenge reste le même, sauf qu’il affecte tout en même temps. Vous vous obligez également à utiliser la même version de SQL server pour tous vos produits.

Et je ne recommande en aucun cas les requêtes entre BDD, les analyses inter-BDD ne n’ont pas de raisons d’arriver en production mais plutôt en aval, dans une datawarehouse.

[CinePhil]

Encore une fois : que faites-vous de l'intégrité référentielle ?

les données redondantes comme les clients ou les produits par exemple ont en général leur propre BDD

L'application commerciale a besoin des clients.
L'application des achats a besoin des fournisseurs et des produits.
L'application de gestion de stock a besoin des produits, voire des fournisseurs.
L'application de gestion de production peut avoir besoin du personnel...

Si ces applications ont leur propre BDD, pas d'intégrité référentielle avec les données communes.

beaucoup d’entreprise se séparent peu à peu de ces BDD uniques monstrueuses qui coutent plusieurs centaines de milliers d’euros par an en licences (les fameux cœurs que Microsoft facture).

Je ne pense pas que l'entreprise de repgarent en soit là, si j'en juge par son système actuel :

en gros on passe du couple infernal excel/access a des appli asp.net

[vince.f]

En effet pas de clé étrangère entre la table produit (donc dans la base « master data ») et une application X utilisant des produits.
Je comprends que ça puisse causer une syncope dans une salle de cours, mais si c’est le seul point qui vous fait réagit dans mon précèdent message et que le rapport positif/négatif ne vous saute pas aux yeux, je ne sais pas trop ce qu’il vous faut.

Je suis loin d’avoir un point de vue arrêté (ces questions évoluent beaucoup trop rapidement pour ca) donc si vous avez des solutions à partager concernant les problèmes que j’ai énoncés, je serais heureux d’en débattre et pourquoi pas d’adopter votre point de vue. Maintenant la BDD unique ça me parait quand même bien loin de ce que des professionnels devraient recommander en 2017 (à part bien sur si, comme je l’ai dit, les applications ont vocation à rester minuscules).

Je ne pense pas que l'entreprise de repgarent en soit là, si j'en juge par son système actuel :

C’est invariablement le genre d’explications qui mènent aux problèmes cités plus haut. Le manque d’anticipation.

[SQLpro]

Il faut cependant savoir que cette distinction entre schéma et BDD est plutôt floue chez MySQL.

Elle n'est pas flou du tout. La notion de schéma SQL n'existe pas dans MySQL, alors que quelques imbéciles font croire le contraire en disant que schéma SQL ou base c'est la même chose !
Or une base, qui comporte plusieurs schéma est un tout intègre alors que différentes bases n'ont aucun moyen de conserver une quelconque intégrité.

Grosso modo la distinction entre schéma et base est la même qu'entre véhicule et sièges.
Un véhicule peut comporter plusieurs places (schéma SQL) et vous pouvez avoir plusieurs véhicules (bases de données).
Mais il n'est pas possible de faire croire que plusieurs véhicules à une seule place sont l'équivalent d'un véhicule à plusieurs places !!!!!!

A +

[SQLpro]

Découplez au maximum vos applications, tout regrouper dans une seule BDD se paye souvent assez cher plusieurs années après.

Ce n'est pas aussi simple et on ne peut pas affirmer de telles énormités sans une analyse fonctionnelle de l'ensemble !

Vous n’avez pas précisé la taille des applications et le nombre d’utilisateurs, mais pour n’importe quoi un tant soit peu sérieux vous allez au-devant de gros casses tètes en terme de maintenance.

Encore une affirmation stupide et péremptoire. La volumétrie n'influe pas sur la structure éclatée ou centralisée de la base. Ce serait même le contraire. En revanche elle dicte le choix du moteur : SQLlite pour les microbases, PG pour les petites (au plus quelques dizaines de Go), PG ou SQL Server pour les moyennes (au plus quelques centaines de Go), SQL Server, Oracle ou DB2 pour les grosses et très grosses (plusieurs To).

...
PS : Faire des requêtes entre plusieurs BDD d’une même instance avec SQL Server est tout à fait possible contrairement à ce qui est dit plus haut.

La encore vous dites des conneries.

Tous les SGBDR permettent de faire des requêtes interbases. Certains nativement et de manière optimisé, c'est le cas de SQL Server et de Sybase. D'autres en implémentant des outils pour ce faire (DBlink par exemple) et sans optimisation. C'est le cas d'oracle ou PostGreSQL.

A +

[SQLpro]

Pensez-vous réellement qu'il est alors préférable d'avoir plusieurs dizaines de BDD différentes, pour une volumétrie au moins égale (il faut toujours stocker les mêmes données) voire supérieure (copie de données entre bases pour assurer ce fameux "découplage" et qui oblige en plus à avoir des système de synchronisation complexes et chronophage) ?

Pour info, un de mes collègues à relevé 25 000 bases sur une même instance pour un volume global de plusieurs To de données sur MS SQL Server...

Un des petits inconvénient, il faut 2h30 pour arrêter le serveur !!!!

C'est effectivement mieux que les 30 secondes habituelles pour un serveur avec quelques bases.... Non !!!

A +

[aieeeuuuuu]

Personne ne vous parle de stocker les mêmes données dans différentes BDD, les données redondantes comme les clients ou les produits par exemple ont en général leur propre BDD avec un seul point d’entrée et de sortie et sont utilisées (par exemple via une API) par x nombre d’applications de façon consistante.

et donc faire les jointures dans l'applicatif ?
Donc par exemple, si l'outil de gestion de stock doit ressortir tous les produits du fournisseur Toto dont le stock est inférieur à X, il faut :
1- Récupérer dans la base de référence tous les produits du fournisseur toto
2 - Récupérer dans la base de l'appli tous les produits dont le stock est inférieur à X, uniquement pour la liste de produit récupérés à l'étape 1 (liste à renvoyer donc au SGBD)
Bien sûr, on s'appuiera pour cela sur des API "génériques", qui ressortent donc tout un tas d'informations sur les produits, inutiles dans le cas présent.
Et l'exemple ici reste une besoin simple...
Je suis prêt à parier que pour résoudre les problèmes de temps de réponse engendrés par une telle archi, il sera vite décidé de copier certaines données sur les produits dans la base de l'appli de gestion de stock, avec tous les problémes de synchro que cela comprend !

Les données des applications elles-mêmes n’ont aucun intérêt à être couplées avec les données de l’entreprise (donc les fameux clients et produits). Si demain vous décidez qu’une de vos applications devient suffisamment critique pour nécessiter son propre server de BDD, vous faites quoi ?

A priori, il y a peu de chance d'en arriver là, (cf remarque de Cinéphil), mais admettons.
Dans ce cas, tous simplement, vous déplacez les données concernées sur un nouveau serveur, et vous remplacez les tables manquantes sur l'existant par des vues pointant vers le nouveau serveur. bref, en une requête dans les tables système, c'est fait !
Ce ne sera pas forcément pire que n'importe quelle autre solution dans une telle situation, et il y en aura surement d'autres plus adaptées en fonction du cas précis quand il se présentera (si tant est qu'il se présente)

Un exemple de problème de maintenance ? Restaurer une BDD qui affecte toutes les applications, installer des mises à jour etc. Le challenge reste le même, sauf qu’il affecte tout en même temps. Vous vous obligez également à utiliser la même version de SQL server pour tous vos produits.

C'est vrai pour le cas de la restauration qui impactera plus largement le SI. Mais au moins toutes les données resteront cohérentes entre elles, et une fois la restauration terminée, vous ne passerez pas deux mois à essayer de résoudre des problèmes dus à un déphasage entre les différentes bases, souvent à la main au cas par cas, et souvent en production, les utilisateurs étant déjà échaudés par l'incident précédent, et pressés de rattraper le temps perdu...
Par ailleurs, vous pouvez prévoir des solutions moins bloquantes dans le PRA si besoin, là encore d'autres solutions existent pour minimiser l'impact, mais cela ce décide en fonction de besoins précis.
En ce qui concerne les mises à jour, si elle nécessitent un arrêt du serveur, ce qui est quand même rare, qu'il y ait une seule ou plusieurs base sur la même instance, le problème sera le même !
Et, bis repetita, en fonction du niveau de service requis, il existe des alternatives.

En effet pas de clé étrangère entre la table produit (donc dans la base « master data ») et une application X utilisant des produits.

Donc, comme je disais, risque par exemple de stocks qui référencent un produit qui n'existe pas...

Je comprends que ça puisse causer une syncope dans une salle de cours,

ça cause surtout des syncopes au DBA qui est appelé pour améliorer les temps de réponses qui deviennent rapidement insupportables. Les données sont eparpillées un peu partout, et il ne dispose même pas des FK pour l'aider à comprendre comment tout ça s'articule.
ça mene aussi à faire des jointure externe à tout va, "au cas où" le produit n'existe pas, réduit les capacités de l'optimiseur...

mais si c’est le seul point qui vous fait réagit dans mon précèdent message et que le rapport positif/négatif ne vous saute pas aux yeux, je ne sais pas trop ce qu’il vous faut.

Si justement, mais on ne voit beaucoup de point négatifs ! comme déjà évoqué : risque de perte d'intégrité, et performances moindres.

Je suis loin d’avoir un point de vue arrêté (ces questions évoluent beaucoup trop rapidement pour ca) donc si vous avez des solutions à partager concernant les problèmes que j’ai énoncés, je serais heureux d’en débattre et pourquoi pas d’adopter votre point de vue. Maintenant la BDD unique ça me parait quand même bien loin de ce que des professionnels devraient recommander en 2017 (à part bien sur si, comme je l’ai dit, les applications ont vocation à rester minuscules).

bases de données distinctes, si les applications n'ont vraiment aucun lien entre elles, ce qui est peu probable, pourquoi pas, mais dans le cas contraire, je persiste et signe...

C’est invariablement le genre d’explications qui mènent aux problèmes cités plus haut. Le manque d’anticipation.

à l'inverse, vouloir tout anticiper mène d'une part à développer des choses qui ne serviront peut-être jamais (ce qui, outre le temps perdu, fini par démotiver les développeurs et complexifier inutilement la maintenance, voire, ironie du sort, complexifier les évolutions). Cela mène d'autre part à des développement plus "génériques", et en matière de base de données, le générique mène souvent à de mauvaises performances. Même la factorisation de code est à faire en connaissance de causes, causes que peu de développeur connaissent...

[vince.f]

Ce n'est pas aussi simple et on ne peut pas affirmer de telles énormités sans une analyse fonctionnelle de l'ensemble !

Une analyse fonctionnelle que l’on n’a pas ici.

Encore une affirmation stupide et péremptoire. La volumétrie n'influe pas sur la structure éclatée ou centralisée de la base. Ce serait même le contraire. En revanche elle dicte le choix du moteur : SQLlite pour les microbases, PG pour les petites (au plus quelques dizaines de Go), PG ou SQL Server pour les moyennes (au plus quelques centaines de Go), SQL Server, Oracle ou DB2 pour les grosses et très grosses (plusieurs To).

Bien sûr que ci, et vos banalités sur le choix du moteur n’ont aucun sens puisqu’ici il est imposé par l’entreprise du premier intervenant : SQL Server 2012 (pourquoi 2012, je ne sais pas).

La encore vous dites des conneries.

Là je pense que vous avez au minimum un problème de lecture, c’est exactement ce que je dis contrairement au précèdent intervenant qui affirmait que ce n’était pas possible.

Maintenant SQL Pro comme je l’ai dit plus haut c’est un sujet qui m’intéresse et je suis friand de retours venant de gens certainement plus expérimentés que moi (« real world » expérience, pas salle de cours et petites applications) donc prenez le temps de lire toutes les interventions et faites-moi le plaisir de nous donner votre opinion sur la question initiale au lieu de vos habituels mélodrames outranciers (qui peuvent être amusants mais qui ne grandissent personne en général).

[aieeeuuuuu]

...
PS : Faire des requêtes entre plusieurs BDD d’une même instance avec SQL Server est tout à fait possible contrairement à ce qui est dit plus haut.

La encore vous dites des conneries.

Heu... bah non, là justement il à raison !

[CinePhil]

Pour mettre fin à la mini polémique... effectivement, JE ne savais pas qu'il fut possible de faire des requêtes sur plusieurs BDD en dehors de MySQL.
Vous m'avez appris un truc... mais que j'espère ne jamais avoir à utiliser... ce qui voudrait dire que je devrais réparer des dégâts causés par l'absence d'intégrité référentielle entre les BDD.

[SQLpro]

Et cette situation est relativement courante, beaucoup d’entreprise se séparent peu à peu de ces BDD uniques monstrueuses qui coûtent plusieurs centaines de milliers d’euros par an en licences (les fameux cœurs que Microsoft facture).

ha oui ? Citez m'en ! Je suis curieux de les connaître. On doit vivre dans des mondes paralèle.. Parce que, pour ma part je constate exactement le contraire : trop de petites bases, de petits serveur que l'on reconcentre sur un seul serveur, voire une seule base afin de faire des économies d'échelle à tous les étages ;
1) moins de serveur => moins de cout matériel et de maintenance
2) des temps de réponse interdatas très largement inférieurs
3) plus de facilité de mettre en œuvre des système de redondance pour assurer un PRA/PCA
...

Un exemple de problème de maintenance ? Restaurer une BDD qui affecte toutes les applications

Peut être ne le savez vous pas, mais il est extrêmement rare pour ne pas dire inutile de restaurer une BD intégralement. Les grands SGBDR savent "réparer" des portions de BD à chaud sans être obligé de restaurer l'intégralité de la base. De plus avec les PCA/PRA intégré la sauvegarde devient inutile et avec la temporalisation des tables, mêmes les erreurs fonctionnelles (effacement logique de données par erreur, ne nécessite aucune restauration... Il serait temps de vous former aux SGBDR modernes, surtout si votre savoir se résumé à Access ou autre merde su même genre !

installer des mises à jour etc.

Il y a longtemps que les mises à jour des SGBDR ne nécessitent pas de redémarrage, même en cas de migration de version, édition... Tout cela se fait à chaud, y compris le rajout de RAM ou de CPU... Mettez vous à la page !!!

Le challenge reste le même, sauf qu’il affecte tout en même temps. Vous vous obligez également à utiliser la même version de SQL server pour tous vos produits.

Encore une affirmation imbécile. De très nombreuses entreprises utilisent des versions différentes de SGBDR sans que cela pose de problèmes majeurs. En particulier sous SQL Server vous pouvez faire cohabiter des bases en version 2005, 2008, 2008 R2, 2012, 2014, 2016 et 2017 sur le même serveur version 2017 et faire des requêtes interbase sans aucun blocage ! Encore une fois formez vous au SGBDR modernesr au lieu de n'y rien comprendre et d'aller voir ailleurs. Cela s’appelle de la largeur d'esprit, chose qui semble vous manquer !

Et je ne recommande en aucun cas les requêtes entre BDD, les analyses inter-BDD ne n’ont pas de raisons d’arriver en production mais plutôt en aval, dans une datawarehouse.

Un DW n'a pas vocation à faire de l'OLTP... Là vous dites n'importe quoi et mélangez différents concepts sans aucun liens !!!!

A

[vince.f]

et donc faire les jointures dans l'applicatif ? ...

C’est un bon exemple d’une des limites de ce type d’architecture. Justement non, rien de générique pour tout ce qui nécessite des performances correctes (donc des requêtes au « moins pires » pour accommoder ces cas-là).
Maintenant votre exemple peut aussi arriver à l’étape suivante, dans la datawarehouse (ou toutes les données seront disponibles au même endroit et qui sera adaptée à ce genre de requêtes).

Mais vous avez raison, la gestion de stock peut-être un bon candidat à l’intégration avec les données produits.

A priori, il y a peu de chance d'en arriver là, (cf remarque de Cinéphil), mais admettons.
Dans ce cas, tous simplement, vous déplacez les données concernées sur un nouveau serveur, et vous remplacez les tables manquantes sur l'existant par des vues pointant vers le nouveau serveur. bref, en une requête dans les tables système, c'est fait !
Ce ne sera pas forcément pire que n'importe quelle autre solution dans une telle situation, et il y en aura surement d'autres plus adaptées en fonction du cas précis quand il se présentera (si tant est qu'il se présente)

Un serveur lié ? Je comprends l’argument, mais cette solution est pire que bien des maux…

C'est vrai pour le cas de la restauration qui impactera plus largement le SI. Mais au moins toutes les données resteront cohérentes entre elles, et une fois la restauration terminée, vous ne passerez pas deux mois à essayer de résoudre des problèmes dus à un déphasage entre les différentes bases, souvent à la main au cas par cas, et souvent en production, les utilisateurs étant déjà échaudés par l'incident précédent, et pressés de rattraper le temps perdu...
Par ailleurs, vous pouvez prévoir des solutions moins bloquantes dans le PRA si besoin, là encore d'autres solutions existent pour minimiser l'impact, mais cela ce décide en fonction de besoins précis.
En ce qui concerne les mises à jour, si elle nécessitent un arrêt du serveur, ce qui est quand même rare, qu'il y ait une seule ou plusieurs base sur la même instance, le problème sera le même !
Et, bis repetita, en fonction du niveau de service requis, il existe des alternatives.

Je ne comprends pas de quels « déphasages » vous parlez et les différentes bases de données ne sont pas nécessairement sur le même serveur physique.

Donc, comme je disais, risque par exemple de stocks qui référencent un produit qui n'existe pas...

Oui, tout à fait. L’intégrité sera garantie là où ça compte, donc pas là. On rentre pratiquement dans le religieux avec ces questions-là donc on peut éventuellement en parler dans un autre topic.

bases de données distinctes, si les applications n'ont vraiment aucun lien entre elles, ce qui est peu probable, pourquoi pas, mais dans le cas contraire, je persiste et signe...

J’entends bien tous vos arguments, et ils ont du sens en terme de base de données. En terme d’application, je maintiens moi aussi qu’en avoir une dizaine ou plus au même endroit est une mauvaise idée, d’autant plus si elles sont développées indépendamment.

SQL Pro, ressaisissez-vous et concentrez-vous sur le sujet initial s’il vous plait. Je suis en effet un expert en Access (et aussi toutes les autres merdes du genre) ce qui semble engendrer chez vous un sévère complexe d’infériorité.
Je prépare à ce propos un livre chez Eyrolles que je me ferais un plaisir de promouvoir à chacune de vos interventions erronées sur Access (en incluant à chaque fois la couverture en pleine page). Ou alors je vous expliquerai calmement comment vous améliorer (histoire de démontrer ma grande largeur d’esprit).

[aieeeuuuuu]

Je ne comprends pas de quels « déphasages » vous parlez et les différentes bases de données ne sont pas nécessairement sur le même serveur physique.

Je parle de perte d'intégrité (en admettant que l'application ait réussi à l'assurer jusque là)
après restauration d'une seules des différentes bases, l'IR risque d'être mise à mal, car vous pourriez avoir perdu des données dans la base restaurée, alors que les autres y font encore référence...

Oui, tout à fait. L’intégrité sera garantie là où ça compte, donc pas là. On rentre pratiquement dans le religieux avec ces questions-là donc on peut éventuellement en parler dans un autre topic.

l'intégrité compte partout !
Et ce point important rentre bien dans le cadre du présent débat, puisque comme déjà dit, sur des bases séparées, pas d'intégrité référentielle déclarative possible, donc moins de perf, en plus du risque de perte d'intégrité.
Ces deux points sont quand même très importants dans le choix d'architecture.