Множество бази данни срещу единична база данни с логически разделени данни

Ще искате да сте използвали отделни бази данни:

• Ако някога искате да дадете разрешения за самите бази данни на клиенти или суперпотребители.
• Ако някога искате да възстановите базата данни само на един клиент, без да засягате данните на останалите.
• Ако има регулаторни опасения, управляващи вашите данни и нарушения на сигурността на данните, и със закъснение откриете, че тези разпоредби могат да бъдат изпълнени само чрез отделни бази данни. (Актуализация:малко повече от 4 години след написването на този отговор, GDPR влезе в сила)
• Ако някога искате лесно да преместите вашите клиентски данни на множество сървъри на база данни или по друг начин да ги мащабирате, или да преместите по-големи/по-важни клиенти на различен хардуер. В друга част на света.
• Ако някога искате лесно да архивирате и деактивирате стари клиентски данни.
• Ако вашите клиенти се интересуват от това, че данните им ще бъдат изолирани и те открият, че сте постъпили по друг начин.
• Ако вашите данни са призовани и е трудно да се извлекат данни само на един клиент, или призовката е твърде широка и трябва да създадете цялата база данни, вместо само данните за един клиент.
• Когато забравите да сте бдителни и се промъкне само една заявка, която не включва AND CustomerID = @CustomerID . Подсказка:използвайте инструмент за скриптови разрешения или схеми, или обвийте всички таблици с изгледи, които включват WHERE CustomerID = SomeUserReturningFunction() , или някаква комбинация от тях.
• Когато получите грешни разрешения на ниво приложение и клиентските данни са изложени на грешен клиент.
• Когато искате да имате различни нива на защита при архивиране и възстановяване за различните клиенти.
• След като осъзнаете, че изграждането на инфраструктура за създаване, осигуряване, конфигуриране, внедряване и по друг начин въртене нагоре/надолу на нови бази данни си струва инвестицията, защото ви принуждава да станете добри в това.
• Когато не сте допуснали възможността някои хора да се нуждаят от достъп до данните на множество клиенти и имате нужда от слой абстракция върху Customer защото WHERE CustomerID = @CustomerID няма да го отрежа сега.
• Когато хакерите се насочат към вашите сайтове или системи и вие ги улеснихте да получат всички данни на всички ваши клиенти с един замах, след като са получили администраторски идентификационни данни само с един база данни.
• Когато архивирането на вашата база данни отнема 5 часа, за да се изпълни и след това е неуспешно.
• Когато трябва да получите изданието Enterprise на вашата СУБД, за да можете да правите компресирани архиви, така че копирането на архивния файл през мрежата да отнеме по-малко от 5 часа още .
• Когато трябва да възстановявате цялата база данни всеки ден на тестов сървър, което отнема 5 часа, и да изпълнявате скриптове за валидиране, които отнемат 2 часа, за да завършат.
• Когато само няколко от вашите клиенти се нуждаят от репликация и трябва да я приложите към всичките си клиенти, вместо само към тези няколко.
• Когато искате да поемете държавен клиент и разберете, че те изискват да използвате отделен сървър и база данни, но вашата екосистема е изградена около един сървър и база данни и просто е твърде трудно или ще отнеме твърде много време за промяна .

Ще се радвате, че сте използвали отделни бази данни:

• Когато пилотно внедряване за един клиент напълно експлодира и останалите 999 клиенти са напълно незасегнати. И можете да възстановите от резервно копие, за да коригирате проблема.
• Когато едно от вашите резервни копия на базата данни е неуспешно и можете да коригирате само това за 25 минути, вместо да стартирате целия 10-часов процес отначало.

Ще искате да сте използвали една база данни:

• Когато откриете грешка, която засяга всичките 1000 клиента и внедряването на корекцията в 1000 бази данни е трудно.
• Когато получите грешни разрешения на ниво база данни и клиентските данни са изложени на грешен клиент.
• Когато не сте допуснали възможността някои хора да се нуждаят от достъп до подгрупа от всички бази данни (може би двама клиенти се сливат).
• Когато не сте мислили колко трудно би било да обедините две различни бази данни с данни.
• Когато сте обединили две различни бази данни с данни и осъзнаете, че едната е грешната, и не сте планирали възстановяване от този сценарий.
• Когато се опитате да надхвърлите 32 767 клиенти/бази данни на един сървър и разберете, че това е максимумът в SQL Server 2012.
• Когато осъзнаете, че управлението на 1000+ бази данни е по-голям кошмар, отколкото някога сте си представяли.
• Когато разберете, че не можете да включите нов клиент само като добавите някои данни в таблица и трябва да изпълните куп страшни и сложни скриптове, за да създадете, попълните и зададете разрешения за нова база данни.
• Когато трябва да изпълнявате 1000 резервни копия на бази данни всеки ден, уверете се, че всички те са успешни, копирайте ги през мрежата, възстановете ги всички в тестова база данни и стартирайте скриптове за валидиране на всяко едно, като докладвате всички грешки по начин, гарантирано ще бъдат видени и които са лесни и бързи за действие. И след това 150 от тях се провалят на различни места и трябва да бъдат поправени един по един.
• Когато разберете, че трябва да настроите репликация за 1000 бази данни.

Това, че изброих повече причини за една, не означава, че е по-добра.

Някои читатели може да получат стойност от MSDN:Multi -Архитектура на данни на клиента . Или може би SaaS Tenancy App Design Patterns . Или дори Разработване на мултитенант Приложения за облака, 3-то издание