Несколько приложение с помощью одной базы данных?
Думайте Дизайн: у Меня есть много приложений, которые совместно используют ту же пользовательскую базу данных! Другие таблицы совместно используются также, такие как пользовательские журналы операций, покупки и т.д.
1) Так или иначе мой вопрос состоит в том, если я должен был подать все заявки, просто используют 1 базу данных для всего! У меня были бы какие-либо проблемы с масштабируемостью? Или какая-либо другая проблема, делающая это? Лучше иметь 1 базу данных?? Или худший?
2) Или я должен просто позволить каждому приложению иметь их собственную базу данных, затем использовать веб-сервис для совместного использования общих таблиц между приложениями?
6 ответов
Чем больше процессов обращается к общему ресурсу, тем выше вероятность возникновения проблем с масштабированием / производительностью и временем.
Я бы не рекомендовал этого делать даже для небольших приложений.
Вероятно, худшей частью всего этого предприятия будет ненужная сложность , которую вы добавите в свой набор приложений. В конце концов, программирование не является линейным, и простое добавление одной таблицы для взаимодействия увеличивает общую сложность более чем в один раз.
По крайней мере, создайте службу для взаимодействия с обычно используемыми таблицами и пусть ваши приложения будут делать запросы через службу.
Я сочувствую вашему желанию объединить ресурсы в одном месте, но я думаю, что в этом случае вы будете настраивать себя на новые трудности в будущем. Я просто не думаю, что оно того стоит.
В ответ на ваши правки ... Я бы выбрал вариант (2).
Даже если у вас была одна база данных, вы все равно могли разделять объекты пользователей с помощью SCHEMAS , тогда вы также можете предоставить пользователям доступ только к их схеме, а не к чужой схеме. . Прочтите о схеме здесь: http://msdn.microsoft.com/en-us/library/ms190387.aspx
Приложения, как правило, копируют организации, которые их создают. Если в базе данных есть два клиента, вас могут попросить внести изменение, которое может нарушить функции, которые использует другой клиент. Поэтому, если у приложения один заказчик, но несколько разных схем, вы можете поместить их в одну базу данных. Если у приложения много клиентов, вы можете разделить их по разным базам данных, даже если схема во многом одинакова - если вам нужно поддерживать возможность развития приложения для одного пользователя, но не для другого.
Blogger (приложение Google) является хорошим примером. Ни у кого из клиентов нет силы просить о функции только для них, поэтому blogger, скорее всего, помещает все в одну схему / одну базу данных.
«Или я должен просто позволить каждому приложению иметь свою собственную базу данных»
В 1950-х годах каждое приложение имело свой собственный частный набор файлов. Примерно через десять лет некоторые умные люди начали замечать, что определенные элементы данных в этих «частных файлах приложений» на самом деле являются дублирующей информацией. Имена клиентов были повсюду, информация о точках продаж дублировалась повсюду и т. Д. И т. Д.
Технология баз данных была изобретена еще более умными людьми для решения этой проблемы.
И теперь, в наши дни, делая базы данных «закрытыми для приложений», поколение интернет-программистов воскрешает те же самые проблемы, которые уже были решены в 1960-х годах.
Просто одна моя мысль, ничего особо важного.
«Те, кто забывают историю, обречены повторять ее». (И это НЕ мысль моей )
Не создавайте отдельные базы данных. Тогда вам придется поддерживать кошмар, и все выйдет из строя. У людей будут разные имена и идентификаторы в разных системах, и это будет худший кошмар, который вы когда-либо видели. Повторяющиеся запросы в одной системе будут соответствовать одному человеку в других, создавая проблемы с отчетами. Было бы неприятно просто писать отчеты, когда пытаетесь привести разрозненные системы в соответствие. Вместо этого планируйте масштабируемость. Узнайте, как разделить данные.
Если у вас есть несколько приложений, обращающихся к одной и той же базе данных, убедитесь, что целостность данных поддерживается базой данных, а не каким-либо приложением! Это критически важно, поскольку в противном случае некоторые приложения могут не знать, как поддерживать определенные вещи, в которых нуждаются другие, и вам придется устранить нарушение целостности данных. Используйте реальные ограничения PK и Fk, определяйте значения по умолчанию, используйте правильные типы данных, чтобы нельзя было вводить недопустимые даты и т. Д.
Не позволяйте разработчикам изменять структуру базы данных без одобрения специалистов по базам данных, которые знают, какими могут быть другие приложения. затронуты изменением. Обязательно научитесь писать эффективный код с первого раза, так как ваш код будет влиять на другие приложения.
Некоторые вещи будут общими для всего вашего бизнеса. Сюда входят пользователи, журналы активности пользователей / аудита и т. Д. Их можно легко поддерживать в одной базе данных без особых усилий.
Некоторые вещи, даже если они имеют общую структуру, должны быть разделены по какой-то деловой причине.Поскольку существует заявленная причина того, что это бизнес-потребность, не имеет значения, проще ли это сделать в одной базе данных или нет - делать это в нескольких базах данных.
Однако некоторые вещи попадают в серую зону. Каждой единице приходится иметь дело с «Заказчиком». Это должно быть в общей базе данных? Могут быть и другие. Кажется, что у этих вещей столько общего, что вы действительно хотите хранить их в одной БД.
Из личного опыта: не надо. Отдельные бизнес-подразделения рассматривают каждую из этих вещей по-разному, и учет всех этих различий может превратить ваши таблицы в кошмар для обслуживания. Если вам нужно хранилище данных, в котором вы можете хранить все свои бизнес-данные, это может быть хорошей идеей, но фактические данные повседневных операций, вероятно, следует хранить в отдельных базах данных, чтобы упростить обслуживание и использование.