Я работаю над приложением, которое собирает данные с смарт-карт. Я хочу, чтобы иметь возможность запускать приложение в качестве веб-службы для нескольких учетных записей клиентов. Вопрос в том, должен ли я создать отдельную базу данных для каждой учетной записи или я должен создать единую базу данных, содержащую данные всех учетных записей? Во-первых, я думал, что единственная база данных является очевидным ответом, но это приводит к тому, что 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" всегда хранят все в одной базе данных?
При разработке приложения с несколькими арендаторами необходимо учитывать несколько факторов, в том числе, по вашему утверждению, дизайн схемы, но также следует учитывать такие вещи, как стоимость лицензии, масштабируемость и т.д. В этой статье описываются три наиболее распространенных подхода к разработке многопользовательского приложения, включая плюсы и минусы. Проверьте это.
Мы прошли оба маршрута. У нас есть общая база данных для небольших клиентов, которым не нужна настройка и отдельная база данных (а также база кода приложения) для корпоративных клиентов, которые это делают.
Оба имеют свои плюсы и минусы. В общей базе данных все, что требуется, - это один плохой запрос, когда кто-то забыл использовать clientid, а данные подвергаются другим клиентам. Через пять лет я видел это только один раз, но это был главный кошмар, который стоил нам клиента. Если вы идете по этому маршруту, убедитесь, что у вас есть хорошая команда QA, которая точно проверяет это до выпуска кода для prod. Если в вашей базе данных есть схемы, вы можете использовать представления в схемах для предотвращения доступа к данным других данных клиента. Если у клиента есть только права на свои взгляды, то они не могут видеть какие-либо другие данные. Это больше подходит для настройки.
Но отдельные базы данных могут стать кошмаром для внесения изменений в техническое обслуживание. Однако, если вы продаете свои апгрейды, это путь, так как не каждый клиент будет покупать каждое обновление. Просто убедитесь, что у вас есть хороший механизм отслеживания, чтобы узнать, в какой версии находится каждый клиент, и что вы используете источник управления для отслеживания всех изменений базы данных по версии, поэтому вы можете легко обновить.
Если вы не собираетесь создавать настройки, вы можете обнаружить, что в любом случае в любом направлении они будут иметь отдельные базы данных. Гораздо проще сказать им, когда они находятся в общей базе данных.
Далее мы обнаружили, что существуют настройки, которые были бы полезны для других клиентов, но поскольку они разработаны в отдельном приложении и базе данных, они перерабатываются другой командой для другого клиента, и вы получаете 6 способов делайте то же самое. Это становится серьезной проблемой для людей, работающих с клиентами, таких как люди, которые импортируют данные клиента в базы данных. Лично я предпочитаю подход с одной базой данных.
Еще один момент, касающийся необходимости консолидации или выделения проблем, связанных с представлением данных. Если отчетность всегда будет выполняться только клиентом, тогда вы можете их разделить, но если вам нужно делать отчетность (например, собственную внутреннюю финуальную отчетность) с консолидированными данными, гораздо проще, если у вас есть сводная база данных. Я приношу это, потому что люди склонны забывать о сообщениях до тех пор, пока дизайн не будет установлен, и это может вызвать некоторые довольно неприятные проблемы, когда вы это делаете.
ИМХО существует только один способ. Несколько баз данных.