Една база данни или много?

Лично аз предпочитам отделни бази данни, по-специално база данни за всеки обект. Харесвам този подход поради следните причини:

1. По-малък = по-бърз по отношение на заявките.
2. Заявките са по-прости.
3. Няма риск от случайно показване на данните на един клиент на друг.
4. Една база данни може да представлява пречка за производителността, тъй като става голяма (увеличаване на броя на обектите). Получавате нещо като изграждане на хоризонтална мащабируемост с 1 на обект.
5. Лесно почистване на данни при премахване на клиенти или юридически лица.

Разбира се, ще отнеме повече време за надграждане на схемата, но според моя опит модификациите са доста необичайни, след като разгърнете, а допълненията са тривиални.

Мисля, че е трудно да се отговори без повече информация.

Облягам се на страната на една база данни. Правилно кодираните бизнес обекти трябва да ви предпазят от забравяне на clientId във вашите заявки.

Типът база данни, която използвате, и начинът, по който тя се мащабира, могат да ви помогнат да вземете решение.

За промените в схемата надолу по пътя изглежда, че една база данни би била по-лесна от гледна точка на поддръжката - имате едно място, където да ги направите.

Какво ще кажете за архивиране и възстановяване? Може ли да срещнете клиент, който иска да възстанови резервно копие за един от своите обекти?

Това е доста нормален сценарий в SAAS приложения с множество клиенти. И двата подхода имат своите плюсове и минуси. Потърсете най-добрите практики за мултитенант SAAS (софтуер като услуга) и ще намерите много неща, върху които да размишлявате.

Вижте тази статия на сайта на Microsoft. Мисля, че върши добра работа, като излага различните разходи и ползи, свързани с дизайна с множество наематели. Вижте също статията за мултитенанциите в wikipedeia. Има много компромиси и най-доброто ви съвпадение до голяма степен зависи от типа продукт, който разработвате.

Един добър аргумент за запазването им в отделни бази данни е, че е по-лесно за мащабиране (можете просто да имате няколко инсталации на сървъра, като клиентските бази данни са разпределени между сървърите).

Друг аргумент е, че след като сте влезли в системата, не е необходимо да добавяте допълнителна проверка where (за клиентски идентификатор) във всяка от вашите заявки.

Така че главна база данни, подкрепена от множество бази данни за всеки клиент, може да бъде по-добър подход,

Ако клиентът някога ще трябва да възстанови само един обект от резервно копие и да остави другите в текущото им състояние, тогава поддръжката ще бъде много по-лесна, ако всеки обект е в отделна база данни. ако те могат да бъдат архивирани и възстановени заедно, тогава може да е по-лесно да се поддържат обектите като единна база данни.

Мисля, че трябва да следвате най-реалистичния сценарий, а не непременно това, което клиентът „може“ да иска да направи в бъдеще. Ако възнамерявате да пуснете на пазара тази функция (т.е. да виждате всичките си обекти в едно табло за управление), тогава трябва или да намерите решение (може би таблото да изтегля от множество бази данни) или да използвате една база данни за цялото приложение.

IMHO, наличието на данни за множество клиенти в една и съща база данни просто ми изглежда като лоша идея. Ще трябва да запомните винаги да филтрирате заявките си по clientID.

Това също зависи от вашата RDBMS, напр.

С SQL сървър базите данни са евтини

С Oracle е лесно да се разделят таблици по клиента "customerID", така че една голяма база данни може да работи толкова бързо, колкото малка база данни за всеки клиент.

Каквото и да изберете, опитайте се да го скриете като ниско ниво в кода си за достъп до данни

Планирате ли да внедрите кода си в множество среди?

Ако е така, опитайте се да го запазите в една база данни и всички препратки към таблици да имат префикс с пространство от имена от конфигурационен файл.

Опцията за единична база данни ще направи поддръжката много по-лесна.