Мне нужно создать приложение Windows, которое представляет несколько "клиентов" в SQL Сервер. Каждый клиент имеет ту же модель данных, но независимую.
какие будут плюсы/минусы Использование нескольких баз данных и использование одной базы данных.
который является лучшим способом для выполнения этой работы. если вы собираетесь для одной базы данных, какие шаги будут делать для этого.
Отредактировано:
Одна вещь - база данных будет размещаться в облачной (rackspace) учетной записи.
Не храните данные у нескольких клиентов в одной базе данных - я знаю компании, которым пришлось потратить много времени/усилий/денег, исправляя эту ошибку. Я даже знал, что клиенты отказываются от совместного использования компьютера базы данных, даже если базы данных раздельные - с положительной стороны, эти клиенты, как правило, готовы платить за дополнительное оборудование.
Проблемы с безопасностью сами по себе должны помешать вам когда-либо делать это. Из-за этого вы потеряете крупных клиентов.
Если у вас есть клиенты, которые не хотят обновлять свое программное обеспечение, это может быть очень сложно, если вы используете одну базу данных. С отдельными базами данных клиент может продолжать использовать старую структуру базы данных до тех пор, пока они не будут готовы к обновлению.
Вы искусственно ограничиваете раздел естественных данных, который может обеспечить значительную масштабируемость для вашего решения. Несколько небольших клиентов могут по-прежнему совместно использовать сервер базы данных, они просто видят свои собственные базы данных/каталоги или могут работать на разных серверах/экземплярах баз данных.
Вы усложняете свой дизайн базы данных, чтобы отличать данные клиентов, которые в противном случае были бы естественным образом разделены, то есть должны были бы поставлять CustomerID в каждое предложение where.
Вы делаете свою базу данных медленнее, имея больше строк во всех таблицах. Вы будете быстрее использовать память базы данных, потому что CustomerID теперь является частью каждого индекса, а меньшее количество записей может храниться в каждом индексе node. Ваша база данных также медленнее из-за потери присущего преимущества локальности ссылки.
Откат данных для одного клиента может быть очень сложным, возможно даже практически невозможным по мере роста базы данных. Для этого вам нужно иметь настраиваемые процедуры, которые намного медленнее и ресурсоемкими, чем простое и стандартное восстановление из резервной копии.
Большие базы данных могут быть очень сложными для резервного копирования/восстановления своевременно, возможно, потребуются дополнительные расходы на аппаратное обеспечение, чтобы сделать это достаточно быстро.
Ваши приложения, которые используют базу данных, будут сложнее поддерживать и тестировать.
Любые ошибки могут быть гораздо более разрушительными, поскольку вы можете испортить всех своих клиентов одной ошибкой.
Вы предотвращаете возможное повышение производительности с низкой задержкой, заставляя свою базу данных находиться в одном месте. Например, зарубежный клиент будет постоянно использовать медленные сети с высокой задержкой.
Вы будете известны как глупый администратор базы данных или безработный администратор баз данных, или, возможно, оба.
Однако существуют некоторые преимущества для разработки общей базы данных.
Общие схемы таблиц, кодовые таблицы, хранимые процедуры и т.д. должны поддерживаться и сохраняться только в 1 месте.
В некоторых случаях стоимость лицензирования может быть уменьшена.
Некоторое обслуживание проще, хотя почти наверняка хуже в целом с использованием комбинированного подхода.
Если все/большинство ваших клиентов очень малы, вы можете иметь низкое использование ресурсов, не объединяя серверы (то есть относительно высокую стоимость). Вы можете смягчить высокую стоимость, объединив клиентов с их разрешением и явным пониманием, но все же используйте отдельные базы данных для более крупных клиентов. В этой ситуации вам определенно необходимо быть явным и открытым с вашими клиентами.
За исключением разделения затрат на сервер, это очень плохая идея, но стоимость также может быть очень важным аспектом. Это действительно единственное оправдание для этого подхода - избегайте этого, если вообще разумно. Возможно, вам будет лучше изменить немного больше для вашего продукта или просто не сможете поддерживать крошечных клиентов по дешевой цене.
Я предполагаю, что несколькими клиентами вы не просто сохраняете информацию о клиентах, вы размещаете базы данных для приложения для клиентов, например, CRM-систем.
Если это так, то я бы абсолютно не хранить все в одной базе данных.
Причины:
Итак, нижняя строка: отдельные базы данных.
В один прекрасный день ваш разработчик что-то испортит, а один клиент получит доступ к информации другого клиента. В результате вы потеряете своих клиентов. Это одно должно сказать вам, что несколько клиентов не могут находиться в одной базе данных. никто не захочет быть вашим клиентом, если они это знают.
Должен ли я действительно решать все проблемы, которые в конечном итоге произойдут, если это так? Ответ прост здесь - НЕТ. Вы не хотите иметь информацию о нескольких клиентах в одной базе данных.
Только время, когда это происходит, - если у вас есть база данных мультиплексора, чтобы отслеживать вход в систему, сеансы и т.д. Но данные, используемые и хранящиеся клиентами, должны быть в выделенной базе данных.
Некоторые из преимуществ каждого рассматриваемого подхода:
Единая база данных
Несколько баз данных