Одиночные или отдельные базы данных для отдельных учетных записей клиентов?

Я работаю над приложением, которое собирает данные с смарт-карт. Я хочу, чтобы иметь возможность запускать приложение в качестве веб-службы для нескольких учетных записей клиентов. Вопрос в том, должен ли я создать отдельную базу данных для каждой учетной записи или я должен создать единую базу данных, содержащую данные всех учетных записей? Во-первых, я думал, что единственная база данных является очевидным ответом, но это приводит к тому, что AccountID нужно использовать практически везде, в таблицах, индексах, ограничениях, запросах, проверках и т.д.

В этом приложении нет ни одного байта данных, который должен быть разделен между учетными записями.

Сначала рассмотрим, как будет выглядеть отдельная база данных для одной учетной записи:

CREATE TABLE CardHolder ( 
 CardHolderID int, -- primary key
 CardHolderUniqueName nvarchar(30) );
CREATE TABLE SmartCard (
 SmartCardID int, -- primary key
 CardHolderID int,
 CardUniqueName nvarchar(30) );

Добавьте к этому несколько ограничений уникальности,

ALTER TABLE CardHolder ADD CONSTRAINT UQ_CardHolderName UNIQUE (CardHolderUniqueName);
ALTER TABLE SmartCard ADD CONSTRAINT UQ_CardName UNIQUE (CardUniqueName);

Теперь, если я помещаю все в одну базу данных, это означает, что несколько учетных записей могут обрабатывать одни и те же карты CardHolders и SmartCards, но учетные записи не должны видеть данные друг друга. Из-за этого смарт-карта уникальна в учетной записи, но не во всей базе данных. Таким образом, каждое ограничение должно включать идентификатор Account,

CREATE TABLE CardHolder ( 
 CardHolderID int, -- primary key
 CardHolderUniqueName nvarchar(30),
 AccountID int );
CREATE TABLE SmartCard (
 SmartCardID int, -- primary key
 CardHolderID int,
 CardUniqueName nvarchar(30)
 AccountID int );
ALTER TABLE CardHolder 
 ADD CONSTRAINT UQ_CardHolderName UNIQUE (AccountID, CardHolderUniqueName);
ALTER TABLE SmartCard
 ADD CONSTRAINT UQ_CardName UNIQUE (AccountID, CardUniqueName);

В фактической БД будет загружено больше таблиц, столбцов и нескольких индексов (для перечисления expirydate и т.д.), а столбец AccountID должен быть включен везде.

Кажется, я немного захламлен, сначала помещаю все учетные записи в одну базу данных, а затем разделяя их, имея столбец AccountID в каждой таблице и почти каждое ограничение и индекс. Мне также нужно было бы найти или изобрести какую-нибудь систему безопасности на уровне строк, чтобы пользователи не могли получать доступ к данным других учетных записей. Итак, есть ли у меня действительное оправдание для создания отдельной базы данных для каждой учетной записи или "реальные дизайнеры db" всегда хранят все в одной базе данных?

3 ответа

При разработке приложения с несколькими арендаторами необходимо учитывать несколько факторов, в том числе, по вашему утверждению, дизайн схемы, но также следует учитывать такие вещи, как стоимость лицензии, масштабируемость и т.д. В этой статье описываются три наиболее распространенных подхода к разработке многопользовательского приложения, включая плюсы и минусы. Проверьте это.


Мы прошли оба маршрута. У нас есть общая база данных для небольших клиентов, которым не нужна настройка и отдельная база данных (а также база кода приложения) для корпоративных клиентов, которые это делают.

Оба имеют свои плюсы и минусы. В общей базе данных все, что требуется, - это один плохой запрос, когда кто-то забыл использовать clientid, а данные подвергаются другим клиентам. Через пять лет я видел это только один раз, но это был главный кошмар, который стоил нам клиента. Если вы идете по этому маршруту, убедитесь, что у вас есть хорошая команда QA, которая точно проверяет это до выпуска кода для prod. Если в вашей базе данных есть схемы, вы можете использовать представления в схемах для предотвращения доступа к данным других данных клиента. Если у клиента есть только права на свои взгляды, то они не могут видеть какие-либо другие данные. Это больше подходит для настройки.

Но отдельные базы данных могут стать кошмаром для внесения изменений в техническое обслуживание. Однако, если вы продаете свои апгрейды, это путь, так как не каждый клиент будет покупать каждое обновление. Просто убедитесь, что у вас есть хороший механизм отслеживания, чтобы узнать, в какой версии находится каждый клиент, и что вы используете источник управления для отслеживания всех изменений базы данных по версии, поэтому вы можете легко обновить.

Если вы не собираетесь создавать настройки, вы можете обнаружить, что в любом случае в любом направлении они будут иметь отдельные базы данных. Гораздо проще сказать им, когда они находятся в общей базе данных.

Далее мы обнаружили, что существуют настройки, которые были бы полезны для других клиентов, но поскольку они разработаны в отдельном приложении и базе данных, они перерабатываются другой командой для другого клиента, и вы получаете 6 способов делайте то же самое. Это становится серьезной проблемой для людей, работающих с клиентами, таких как люди, которые импортируют данные клиента в базы данных. Лично я предпочитаю подход с одной базой данных.

Еще один момент, касающийся необходимости консолидации или выделения проблем, связанных с представлением данных. Если отчетность всегда будет выполняться только клиентом, тогда вы можете их разделить, но если вам нужно делать отчетность (например, собственную внутреннюю финуальную отчетность) с консолидированными данными, гораздо проще, если у вас есть сводная база данных. Я приношу это, потому что люди склонны забывать о сообщениях до тех пор, пока дизайн не будет установлен, и это может вызвать некоторые довольно неприятные проблемы, когда вы это делаете.


ИМХО существует только один способ. Несколько баз данных.

  • Это не только полностью защищенные данные, которые ДОЛЖНЫ НИКОГДА не использоваться.
  • Он также позволяет изменять схемы независимо друг от друга. Под этим я подразумеваю, что со временем, возможно, один арендатор намного больше, чем все другие чайанцы, и, следовательно, необходимо удовлетворить особые потребности.
  • Резервное копирование, операции восстановления и стратегии могут быть легко сформулированы для независимых баз данных.
  • Ограничения и уникальность легче и более естественно выражены

licensed under cc by-sa 3.0 with attribution.