Плюсы / минусы использования нескольких баз данных против использования одной базы данных

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

1. проблемы только с безопасностью должны помешать вам когда-либо делать это. Вы потеряете крупных клиентов поэтому.

2. Если у вас есть некоторые клиенты, которые не хотят обновлять свое программное обеспечение, это может быть очень сложно, если вы используете одну базу данных. Отдельные базы данных позволяют клиентам продолжать использовать старую структуру базы данных до тех пор, пока они не будут готовы к обновлению.

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

4. вы усложняете свой дизайн базы данных, потому что вам придется различать данные клиента, которые в противном случае были бы естественно разделены, т. е. должны предоставлять CustomerID для каждого предложения where.

5. вы делаете свою базу данных медленнее, имея больше строк во всех таблицах. Вы будете использовать память базы данных быстрее, потому что CustomerID теперь является частью каждого индекса, и в каждом узле индекса может храниться меньше записей. Ваша база данных также работает медленнее из-за потери неотъемлемого преимущества locality of reference.

6. откат данных для 1 клиента может быть очень сложным, возможно, даже практически невозможным, поскольку база данных растет - вам понадобятся пользовательские процедуры для этого, которые намного медленнее и ресурсоемки, чем простое и стандартное восстановление из резервное копирование.

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

8. ваши приложения, которые используют базу данных, будет сложнее поддерживать и тестировать.

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

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

11. вы будете известны как глупый DBA, или безработный DBA, или, может быть, оба.

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

1. общие схемы таблиц, таблицы кодов, хранимые процессы и т. д. нужно только поддерживать и хранить в 1 местоположение.

2. в некоторых случаях стоимость лицензирования может быть снижена.

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

4. Если все / большинство ваших клиентов очень малы, вы можете иметь низкое использование ресурсов, не объединяя серверы (т. е. относительно высокую стоимость). Вы можете уменьшить высокую стоимость, объединив клиентов с их разрешением и явным пониманием, но все еще используйте отдельные базы данных для больших клиентов. Вы определенно должны быть откровенны и откровенны со своими клиентами в этой ситуации.

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