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

Слушайте подкаст Stackoverflow, где Joel и Jeff говорят о том же самом вопросе. Joel говорит об их опыте, предлагающем размещенную версию их программного обеспечения. Он указывает, что добавление клиентских идентификаторов на всем протяжении Вашего DB усложняет дизайн и код (действительно ли Вы уверены, что случайно не забыли добавлять его к некоторому оператору Where?) и усложняет функцию хостинга, такую как определенные для клиента резервные копии.

Это было в эпизоде № 20, или № 21 (проверьте расшифровки стенограммы на детали).

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

Думают о резервном копировании базы данных. Клиент A говорит, "Отправьте мне копию моих данных". Очень, намного легче в отдельной базе данных устанавливают, чем если бы единая база данных совместно используется. Думайте об удалении клиента; снова, намного легче с отдельными базами данных.

(Часть 'инфраструктуры' является неискренней, потому что существуют существенные различия между различным DBMS о том, что составляет 'базу данных' по сравнению с 'экземпляром сервера', например. Добавляют : вопрос отмечен 'mysql', поэтому возможно, те мысли не абсолютно релевантны.)

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

Очевидно, StackOverflow (как пример) не имеет отдельной базы данных на пользователя; все мы используем ту же базу данных. Но если бы Вы выполняли системы учета для различных компаний, я не думаю, что для компаний, и возможно не легальным людям) было бы приемлемо (совместно использовать базы данных.

• РАЗРАБОТКА Для быстрой разработки, используйте базу данных на клиента. Думайте, как легкий это должно будет скопировать, восстановите или удалите данные клиента. Или измерять/контролировать/тарифицировать использование. Вы не должны будете писать код, чтобы сделать это собой, просто использовать Ваши примитивы базы данных.

• ПРОИЗВОДИТЕЛЬНОСТЬ Для производительности, используйте базу данных для всех. Думайте об организации пула подключений, общей памяти, кэшировании, и т.д.

• БИЗНЕС , Если Ваш бизнес-план состоит в том, чтобы иметь много маленьких клиентов (думайте hotmail), необходимо, вероятно, работать над единственным DB. И имейте все задачи администрирования такая регистрация, удаление, миграция данных, и т.д. полностью автоматизированная и выставленная в дружественном интерфейсе. Если Вы планируете иметь десятки или до нескольких сотен крупных клиентов затем, можно работать в одном дБ на клиента и иметь сценарии системного администрирования на месте, которые могут управляться штатом поддержки клиентов.

Для коллективной аренды производительность будет обычно увеличивать больше ресурсов, которые Вам удается совместно использовать через арендаторов, видеть

http://en.wikipedia.org/wiki/Multitenancy

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

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

Другой вопрос для рассмотрения - то, что у Вас может быть юридическое обязательство разделить данные одной компаний от anothers'.

Наличие базы данных на клиент обычно не масштабируется хорошо. MySQL (и вероятно другие базы данных) содержит ресурсы, открытые на таблицу, это не предоставляет себя хорошо 10k + таблицы на одном экземпляре, который произошел бы в крупномасштабной ситуации с коллективной арендой.

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

Кроме того, "sharding" многопользовательское приложение likelyв‚ ¬, чтобы быть правильным поступком в конечном счете, поскольку Ваше приложение становится больше и больше.

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

в‚ ¬ я не могу гарантировать его.

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

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

2), Когда у Вас есть только одна база данных, удостоверьтесь, что она поддерживается до другого физического сервера. В случае обработки отказа можно вернуться трафик к этому другому серверу и все еще иметь неповрежденные данные.

В следующем скринкасте объясняется, как это делается на salesforce.com. Они используют одну базу данных со специальным столбцом OrgId, который идентифицирует данные каждого клиента. Это еще не все, так что вам стоит изучить это. Я бы согласился с их подходом.

На MSDN есть еще одна замечательная статья об этом. В нем подробно объясняется, когда следует использовать общий или изолированный подход. Помните, что наличие общей БД для всех ваших клиентов имеет некоторые важные последствия для безопасности, и если все они используют одни и те же объекты БД, вы можете захотеть использовать [безопасность на уровне строк] - в зависимости от СУБД, которую вы используете (я уверен, что это возможно в MS SQL Server и Oracle, возможно, и в IBM DB2). Вы можете использовать уловки вроде безопасности на уровне строк в mySQL для достижения аналогичных результатов (представления + триггеры).