Несколько приложений с использованием одной базы данных?

Ответ 1

Чем больше процессов вы получаете доступ к общему ресурсу, тем больше вероятность того, что вы столкнетесь с проблемами масштабирования/производительности и времени.

Даже если ваши приложения небольшие, я бы рекомендовал против этого.

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

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

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

В ответ на ваши изменения... Я бы выбрал вариант (2).

Ответ 2

"Или я должен просто позволить каждому приложению иметь собственную базу данных"

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

Технология базы данных была изобретена еще более умными людьми для решения этой проблемы.

И теперь, в наши дни, создавая базы данных "частное приложение", поколение интернет-программистов возрождает те же проблемы, которые были решены в 1960-х годах.

Просто моя мысль, ничего действительно важного.

"Те, кто забывают историю, обречены повторять ее". (И это НЕ моя мысль)

Ответ 3

Не создавайте отдельные базы данных. Тогда у вас будет кошмар для поддержания, и все выйдет из строя. Люди будут иметь разные имена и идентификаторы в разных системах, и это будет худший кошмар, который вы когда-либо видели. Dups в одной системе будет соответствовать одному человеку в других, создавая проблемы с отчетами. Просто писать отчеты, пытаясь получить разрозненные системы для соответствия, будет неприятно. Вместо этого планируйте масштабируемость. Узнайте, как разделять данные.

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

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

Ответ 4

Даже если бы у вас была одна база данных, вы все равно могли бы разделять пользовательские объекты с помощью SCHEMAS, тогда вы также можете предоставить пользователям доступ к их схеме, а не ко всем другим схемам. Читайте о схеме здесь: http://msdn.microsoft.com/en-us/library/ms190387.aspx

Ответ 5

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

Хорошим примером является Blogger (приложение Google). Ни один из клиентов не имеет желания запрашивать функцию только для них, поэтому блоггер, скорее всего, помещает все в одну схему/одну базу данных.

Ответ 6

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

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

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

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

Ответ 7

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