Budete si přát, abyste používali samostatné databáze:
- Pokud někdy budete chtít udělit oprávnění k samotným databázím klientům nebo superuživatelům.
- Pokud někdy budete chtít obnovit databázi pouze jednoho klienta, aniž byste ovlivnili data ostatních.
- Pokud existují regulační obavy týkající se vašich dat a porušení ochrany dat a opožděně zjistíte, že tyto předpisy lze splnit pouze tím, že budete mít samostatné databáze. (Aktualizace:něco málo přes 4 roky po napsání této odpovědi vstoupilo v platnost GDPR)
- Pokud někdy budete chtít snadno přesunout svá zákaznická data na více databázových serverů nebo jinak škálovat nebo přesunout větší/důležitější zákazníky na jiný hardware. V jiné části světa.
- Pokud někdy budete chtít snadno archivovat a vyřadit stará data zákazníků.
- Pokud vašim zákazníkům záleží na tom, aby jejich data byla ukládána do zásobníku, a zjistí, že vy jste to udělali jinak.
- Pokud jsou vaše data předvolána a je obtížné získat pouze data jednoho zákazníka, nebo je předvolání příliš široké a musíte vytvořit celou databázi namísto pouze dat pro jednoho klienta.
- Když zapomenete zachovat ostražitost a proklouzne jen jeden dotaz, který nezahrnuje
AND CustomerID = @CustomerID. Nápověda:použijte skriptovaný nástroj pro oprávnění nebo schémata nebo zabalte všechny tabulky pohledy, které zahrnujíWHERE CustomerID = SomeUserReturningFunction(), nebo nějakou jejich kombinaci. - Když získáte nesprávná oprávnění na úrovni aplikace a zákaznická data jsou vystavena nesprávnému zákazníkovi.
- Pokud chcete mít různé úrovně ochrany zálohování a obnovy pro různé klienty.
- Jakmile si uvědomíte, že vybudování infrastruktury pro vytváření, poskytování, konfiguraci, nasazení a další vytváření nových databází stojí za investici, protože vás to nutí se v tom zdokonalovat.
- Když jste neumožnili, aby určitá třída lidí potřebovala přístup k datům více zákazníků, a potřebujete vrstvu abstrakce navrch
CustomerprotožeWHERE CustomerID = @CustomerIDteď to nepřeruším. - Když se hackeři zaměří na vaše stránky nebo systémy a vy jste jim usnadnili získat všechna data všech svých zákazníků jedním tahem poté, co jste získali pověření správce pouhým jedním databáze.
- Když zálohování databáze trvá 5 hodin a pak selže.
- Když si musíte pořídit edici Enterprise vašeho DBMS, abyste mohli vytvářet komprimované zálohy, takže kopírování záložního souboru po síti zabere méně než 5 hodin více .
- Když musíte každý den obnovit celou databázi na testovací server, což trvá 5 hodin, a spouštět ověřovací skripty, jejichž dokončení trvá 2 hodiny.
- Když replikaci potřebuje jen několik vašich zákazníků a vy ji musíte použít u všech zákazníků, nikoli jen u těch několika.
- Když se chcete ujmout vládního zákazníka a zjistíte, že po vás vyžaduje použití samostatného serveru a databáze, ale váš ekosystém byl postaven na jediném serveru a databázi a změna je příliš náročná nebo bude trvat příliš dlouho .
Budete rádi, že jste použili samostatné databáze:
- Když pilotní zavedení u jednoho zákazníka úplně exploduje a dalších 999 zákazníků se to úplně nedotkne. A problém můžete vyřešit obnovením ze zálohy.
- Když selže jedna z vašich záloh databáze a vy můžete opravit pouze tuto za 25 minut, místo abyste celý 10hodinový proces začínali znovu.
Budete si přát, abyste používali jedinou databázi:
- Když objevíte chybu, která ovlivňuje všech 1000 klientů, a nasazení opravy do 1000 databází je obtížné.
- Když získáte nesprávná oprávnění na úrovni databáze a zákaznická data jsou vystavena nesprávnému zákazníkovi.
- Když jste neumožnili, aby určitá třída lidí potřebovala přístup k podmnožině všech databází (možná se sloučili dva zákazníci).
- Když jste si nemysleli, jak těžké by bylo sloučit dvě různé databáze dat.
- Když sloučíte dvě různé databáze dat a uvědomíte si, že jedna z nich byla nesprávná, a neplánovali jste zotavení z tohoto scénáře.
- Když se pokusíte překročit 32 767 zákazníků/databází na jednom serveru a zjistíte, že toto je maximum v SQL Server 2012.
- Když si uvědomíte, že správa více než 1 000 databází je větší noční můra, než jste si kdy dokázali představit.
- Když si uvědomíte, že nového zákazníka nemůžete získat pouhým přidáním dat do tabulky a musíte spustit spoustu děsivých a komplikovaných skriptů k vytvoření, naplnění a nastavení oprávnění pro novou databázi.
- Když musíte každý den spouštět 1000 záloh databází, ujistěte se, že jsou všechny úspěšné, zkopírujte je přes síť, obnovte je všechny do testovací databáze a na každé z nich spouštějte ověřovací skripty, které hlásí všechna selhání způsobem, který budou zaručeně vidět a které jsou snadno a rychle použitelné. A pak 150 z nich selže na různých místech a je třeba je opravit jeden po druhém.
- Když zjistíte, že musíte nastavit replikaci pro 1000 databází.
To, že jsem uvedl více důvodů pro jeden, neznamená, že je lepší.
Někteří čtenáři mohou získat hodnotu z MSDN:Multi – Architektura dat nájemců . Nebo možná Vzory návrhu aplikací SaaS Tenancy . Nebo dokonce Vývoj pro více nájemců Aplikace pro cloud, 3. vydání