Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Le modèle de tenancy 3d71 Recommandé

Le tenant n'est pas une fatalité, c'est un curseur — et il faut le séparer de la récupération. Le bon défaut : le revendeur.

Dans la chaîne éditeur → revendeur → client final, là où tu places la frontière du tenant tu fixes du même coup la portée de la dédup et celle de l’oracle (point 4d8e). Les trois options sont littéralement des portées emboîtées :

Éditeur Rev. A Rev. B A1 A2 B1 B2

tenant = client final

Isolation maximale. Quasi aucune dédup — rien n'est partagé entre clients d'un même revendeur.

isolation max
Éditeur Rev. A Rev. B A1 A2 B1 B2

tenant = revendeur

Dédup sur tout le parc du revendeur (OS, docs communs → grosses économies). Oracle confiné à l'intérieur.

recommandé
Éditeur Rev. A Rev. B A1 A2 B1 B2

tenant = éditeur

Dédup maximale, mais l'oracle traverse les revendeurs concurrents. À éviter.

oracle global

Le gain de la portée éditeur — les fichiers d’OS et bibliothèques communes — est de toute façon déjà présent à l’intérieur du parc d’un revendeur. La portée revendeur le capte donc sans ouvrir l’oracle aux concurrents.

Et c'est configurable Un revendeur qui sert des entreprises mutuellement méfiantes bascule sur tenant = client final, au prix de la dédup partagée. Le curseur reste un paramètre, pas une décision gravée.