Архитектура программного обеспечения и дизайн баз данных: одна база данных/веб-приложение для каждой компании или одна база данных/веб-приложение для всех компаний?

Question

Я разрабатываю веб-приложение базы данных SQL с нуля. Приложение будет управлять информацией для клиентов, работающих в одном и том же виде. Другими словами, информация (сущности и отношения между ними) относительно каждого клиента не меняется слишком сильно от одного к другому. Однако объем информации диктуется размером компании. Приложение может быть размещено на нашем сервере (серверах) или в любом месте, который выбирает клиент.

Мой первый вопрос: каковы плюсы и минусы, учитывая следующие параметры:

• A. Управление несколькими клиентами информации в той же базе данных;
• B. Управляйте информацией одного клиента в базе данных ; поэтому каждый клиент будет иметь свою собственную базу данных;

Мой второй вопрос: какие плюсы и минусы имеют следующие методы развертывания?

• A. Каждый клиент получает свой собственный сервер (узел);
• B. Используйте большой RAID-диск (ы) с одним мощным сервером с несколькими веб-сайтами;

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

Используемые технологии:

• базы данных: MS SQL
• Платформа: ASP.NET
• Язык: C#

Все комментарии и предложения являются наиболее приветствовать,

Спасибо ,

Cullen

Answer 1

Я бы не стал рекомендовать каждому клиенту собственную базу данных. Я планировал сделать это для своего текущего приложения и был заговорен в одной базе данных. Хорошо, потому что теперь у нас 300 клиентов. Можете ли вы представить себе управление 300 базами данных? Обновление каждого из них при каждом обновлении? Убедитесь, что каждый обновлен и т. Д.

Отказ от ответственности: На практике у нас фактически есть несколько баз данных. Несколько очень крупных клиентов имеют свою собственную базу данных, а другие - остальные. Я думаю, может быть, 7 баз данных.

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

Answer 2

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

Общая тенденция в отрасли программного обеспечения для бизнеса прямо сейчас централизует ваше приложение на свои собственные серверы и предоставляет программное обеспечение как услугу для ваших клиентов.

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

Если вас беспокоит стоимость оборудования, вы можете посмотреть на услуги облачного хостинга, такие как Amazon s2, Google App Engine и Microsoft Azure.

Answer 3

Вы действительно хотите просмотреть следующее:

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

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

* обновляется по новой ссылке

Answer 4

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

Создайте приложение, чтобы несколько клиентов могли существовать в одной базе данных. (т. е. создать слой разделения между данными клиента). Затем планируйте, чтобы все это было в одной базе данных.

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

Answer 5

У меня есть опыт работы арендатор дизайн около 40 клиентов. Каждый клиент имеет отдельные файлы приложений ASP.NET и базу данных SQL Server. Бинарные двоичные файлы приложений одинаковы для каждого клиента, но клиенты также имеют настраиваемые модули.

Я бы рекомендовал сначала сконструировать всю систему как многопользовательскую, но при необходимости сохранить один арендатор. Я думаю, что причина, по которой мы ездили на одного арендатора, была вызвана спросом со стороны клиентов. Многие из наших клиентов запускают приложение внутри своих интрасетей.

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

Pros

• Хорошо для бизнеса программного обеспечения. Легко настроить, но вы все равно получите выгоду от повторного использования
• Мы можем использовать экземпляры SQL Express на сервер, пока каждая база данных под 4GB
• Много разделения между клиентами.Например, каждый клиент может иметь отдельный пул приложений IIS
• безопасность на еще системном уровне, не совсем на уровень приложений
• версия программного обеспечения одного клиента может быть заморожена в течение длительного времени
• Ошибки обычно не поверхности на каждом клиенте
• Новые функции могут быть созданы красиво на основе фактического спроса клиентов. Первые клиенты для функции в основном бета-тестеры

Против

• плохи для потребителей программного обеспечения. Не ожидайте значительного масштабирования
• Техническое обслуживание является трудоемким: обновления, резервное копирование, отладка специфических для клиента проблем ...
• Контроль качества сложнее, если версии немного отличаются. Неожиданные неприятности после обновлений

Answer 6

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

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

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

Будут ли приложения когда-либо настраиваться, и если да, то одна из них вызовет проблемы?