Когда следует создавать новую базу данных, а не новые таблицы в существующей базе данных?

Question

Когда следует создавать новую базу данных, а не новые таблицы в существующей базе данных?

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

Другими словами, когда имеет смысл добавлять новые таблицы в новую базу данных, а не в существующую базу данных?

Спасибо.

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Вы, возможно, захотите, чтобы каждый отдельный фрагмент программного обеспечения (каждый форум, блог и т. Д.) Имел свою собственную базу данных, когда это возможно. Хорошее практическое правило: если вам нужно установить его, поместите его в свою собственную БД.

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

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

Answer 4

Это просто вопрос , означающий .

База данных имеет какое-то значение: какое-то утверждение или цель, определение или причина существования.

Если нет«значение», затем поместите все данные в одну базу данных, пока значение не будет улажено.

создать новую базу данных и добавить туда таблицы форума?

Никогда.Это разделяет что-то на несколько баз данных.Смысл в базе данных состоит в том, чтобы держать вещи вместе, чтобы вы могли работать над связанными вещами в одной базе данных.