2010-09-12 25 views
3

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

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

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

+0

Как вы думаете, плоские файлы не будут работать? –

+0

Ну ... может быть, так и будет. Я могу попробовать их, но я хотел бы посмотреть, какие параметры базы данных есть. –

+1

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

ответ

3

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

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

+0

+1 для теории и базы данных первого курорта – msw

+0

Я определенно заинтересован в изучении теории. Причина, по которой я спрашиваю, не будет ли база данных SQL ограничивать количество игроков, которых я могу иметь в игре, потому что она фиксирует количество столбцов, которые у меня есть? И если это произойдет, применит ли теория реляционных баз данных к другим типам баз данных? Или я хотел бы изучить реляционную теорию как prereq для других видов? –

+1

Реляционная является доминирующей технологией DBM и была в течение последних 40 лет. Поле хорошо протоптано, как в академическом, так и в практическом плане, и я не могу себе представить, как это необходимо. «Структурированное хранилище» - это новый ребенок на блоке, и люди все еще пытаются понять, как наилучшим образом его использовать (см. Http://en.wikipedia.org/wiki/NoSQL). Я бы не предложил его как первый шаг для неофита DBM. – msw

7

Я не вижу каких-либо критериев, выбор базы данных воздействий, но я перечислю свободные одни:

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

Вы хотите узнать о нормализации, получение данных в Третью нормальную форму (3NF), поскольку она обеспечивает ссылочную целостность, что также сводит к минимуму избыточность данных. Например, статистика игрока не будет храниться в базе данных - они будут вычислены во время запроса на основе данных.

+0

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

+0

MySQL иногда свободен, иногда нет: это двойная лицензия :( –

+0

Встраиваемые Firebird имеют те же функции, что и Firebird Server, поэтому где компромиссы? –

3

Некоторые хорошие варианты уже упоминались, но я действительно думаю, что на платформе Java H2 - очень хороший выбор. Он идеально подходит для тестирования (в тестовой базе данных), но отлично работает и для встроенных приложений и как самостоятельная «настоящая база данных». Кроме того, легко экспортировать файл дампа, импортировать из него, чтобы перемещаться. И работает эффективно. Он разработан очень хорошим парнем Java DB и не является его первым занятием, и вы можете видеть это со зрелости проекта. Кроме того, он все еще активно развивается, а также поддерживается.

+0

Спасибо! Я обязательно рассмотрю этот вопрос, как только я знаю, как обращаться с базами данных в общем (потому что, по-видимому, я действительно этого не делаю!) –

+0

+1 У меня были отличные впечатления от H2. Автор также является участником SO. – trashgod

0

Попробуйте также OrientDB. Это бесплатно (лицензия Apache 2), работает везде, поддерживает SQL, и это очень быстро. Может вставить 1 000 000 записей за 6 секунд на общем hw.

+1

Пожалуйста, напишите полное раскрытие информации о вашей аффилированности, как указано в [FAQ] (http://stackoverflow.com/faq) (упоминание об этом в вашем профиле также было бы хорошей идеей). –

+0

Выполнено в моем профиле – Lvca

1

Слово о том, почему никто даже не упоминает о какой-либо из баз данных «NoSQL» в то время как вы использовали его в качестве метки:

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

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

Смежные вопросы