Как спроектировать БД для нескольких проектов

Question

Мне интересно, как лучше организовать мою БД.Позвольте мне объяснить:

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

Одна вещь, которая объединяет все проекты, - это пользователи, которые собираются ее использовать.

Итак, мои вопросы:

• Должен ли я создать разные БД для каждого из небольших проектов (в настоящее время каждый проект будет содержать 4-5 таблиц)
• Как справиться спользователей?Должен ли я создать одну БД для всех пользователей или я должен дублировать таблицу пользователей в каждой БД?Имейте в виду, что информация о пользователях часто используется в каждом небольшом проекте, она не только для целей идентификации.

Заранее благодарим за ваш совет.

Answer 1

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

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

На вопрос о том, как спроектировать вашу базу данных, трудно ответить без дополнительной информации. В большинстве архитектур «функции» в приложении, как правило, тесно связаны - «пользователи» связаны с «учетными записями», связаны с «организациями» и т. Д.

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

Под «жизненным циклом» я подразумеваю в основном жизненный цикл разработки - приложение 1 может развертываться еженедельно, приложение 2 - ежемесячно, приложение 3 - только один раз, а затем останавливаться.

Answer 2

Я думаю, что правильный ответ «это зависит».

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

однако:

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

Answer 3

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

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

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

В случае базы данных, такой как MySQL, я рекомендую вам выбрать короткий префикс для каждого подпроекта и соответствующим образом префикс всех таблиц.Например, «P1_Customer».

Общие данные будут иметь собственную схему или префикс, например, Global или что-то в этом роде.

На самом деле, это было одной из многих причин, по которым мы переключили нашу основную базу данных.из MySQL в PostgreSQL.Мы оба были активными пользователями обоих, и я действительно ценю функции, которые предлагает PostgreSQL.SQL Server, если вы находитесь в среде Windows, также является отличной базой данных IMO.

Answer 4

Если маленькие проекты - это «особенности большого», то я не вижу причины, по которой вы бы не захотели использовать одну таблицу user для основного проекта.То, как вы задали вопрос, делает это правдоподобным: «Если в небольшом проекте 1 есть пользователь A, то в« большом »проекте должен быть пользователь A».Если это правда, вы, скорее всего, должны иметь пользователей в большом БД вместо дублирования, если у вас нет более подробной информации.