5 отдельных баз данных или 5 таблиц в 1 базе данных?

Question

Допустим, я хочу создать игровой сайт, и у меня есть много игровых разделов. ВСЕ они имеют много данных, которые должны быть сохранены. Лучше сделать одну базу данных с таблицей, представляющей каждую игру, или иметь базу данных, представляющую каждый раздел игры? Я ожидаю ответа типа «зависит».

Answer 1

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

• Если это экспорт и импорт, то делайте отдельные базы данных.
• Если это нормальные отношения (с внешними ключами и перекрестными запросами), то оставьте их в одной базе данных.

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

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

Разница была довольно простой:

• Внешняя база данных хранит только те факты, которые вы не можете изменить или отменить. Это были телефонные звонки, SMS сообщения и входящие платежи в нашем случае.

• Внутренняя база данных хранит то, что обычно хранится: пользователи, пароли и т. Д.

База данных external использует только натуральные PRIMARY KEY, которые были телефонными номерами, банковской транзакцией id и т. Д.

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

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

Answer 2

Я не уверен, что это правильно, но я думаю, что вы хотите создать одну базу данных с 5 таблицами, потому что (наряду с другими причинами) влияние альтернативы на пул соединений (если, например, вы используете ADO). Сеть). В пуле соединений ADO.Net соединения основываются на строке соединения, поэтому при наличии пяти разных баз данных вы можете получить до 20 соединений с каждой базой данных вместо 100 соединений с одной базой данных, что потенциально может повлиять на гибкость распределения соединений. .

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

Answer 3

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

Answer 4

Действительно зависит:) ..

Задайте себе эти вопросы:

Может ли быть необходимость в переопределении (таблица пользователей), о котором я могу подумать? Стоит ли разделять эти объекты или они почти одинаковы? У какого-либо из этих субъектов есть определенные события / потребности? Стоит ли мне тратить время и силы на создание 5 разных систем баз данных (помните, если вы пишете игры, которые подразумевают разные строки подключения, а также обеспечивают большую безопасность и т. Д.).

Или вы можете создать одну базу данных OnlineGames и иметь таблицу, в которой хранятся название игры и категория:

PacMan Arcade

Ролевая Зельда

и т. Д. И т. Д.

Это действительно зависит от ваших намерений ...

Answer 5

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

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

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

Размер данных
Размер данных не должен быть фактором в этом решении.

Answer 6

Просто добавить немного. Когда в одной игре участвуют миллионы и миллионы игроков, а ваша игра в режиме реального времени, и у вас есть десятки тысяч одновременных игроков онлайн, и вы должны как минимум сохранять некоторые важные данные как можно более актуальными в БД (скажем, виртуальный игрок Деньги). Тогда вы захотите разделить таблицы на независимые БД, даже если они все «связаны».

Это действительно зависит. И масштабирование будет болезненным, что бы вы ни пытались сделать, чтобы избежать боли. Но если вы действительно ожидаете МНОГО игроков, обновлений и данных, я бы посоветовал подумать дважды, трижды и более, прежде чем остановиться на решении «одна БД для нескольких проектов».

Да, возможно, будет сложно управлять несколькими БД. Но вам все равно придется это сделать.

Answer 7

Что вы думаете о «большом количестве данных»? Единственная причина, по которой вам нужно разделить это по нескольким базам данных, - это если вы пытаетесь сэкономить немного денег с помощью общего хостинга (то есть, получить дешевые общие хосты и разделить его по серверам), или если вы чувствуете, что каждая база данных будет в 500 ГБ диапазон и не имеют доступа к соответствующему хранилищу.

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

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

У некоторых компаний есть отдельные базы данных в диапазоне от 1000 ТБ ... в основном нет верхней границы размера базы данных.