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

Question

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

Answer 1

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

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

Answer 2

Зависит.

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

Одна база данных.

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

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

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

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

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

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

Answer 6

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

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

Answer 7

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

Answer 8

Оборонительно, одна база данных

Answer 9

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

Answer 10

Я могу передать свой опыт в аналогичной ситуации.

У нас было 4 «общих» базы данных и около 30 «специфических» баз данных, разделенных по тем же пространственным соображениям. Недостатком является то, что проблемы с пространством просто проецировали недостатки dBase на SQL Server. В итоге мы получили все эти базы данных на SQL Server Enterprise, размер которых значительно превышал максимальный размер, допустимый для редакции Desktop.

С точки зрения базы данных с точки зрения разделения интересов, 4 общих базы данных могли бы быть 2. 30 конкретных баз данных могли бы быть 3 (или даже 1 с достаточным количеством манипуляций / обобщений). Это был неэффективный код (как хранимые процедуры, так и код уровня доступа к данным) и схема таблиц, которые определяли множество баз данных; в конце концов, это не имело ничего общего с пространством.

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