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