Можете ли вы дать несколько советов по настройке моей базы данных?

Question

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

Однако я никогда раньше не работал с базами данных, поэтому мне было интересно, есть ли у вас какие-либо советы о том, как это настроить?

• В каком формате хранить данные?
  • Я думал о сохранении объекта Dictionary в базе данных для каждой сущности. Таким образом, я мог бы просто добавить новые атрибуты в базу данных на лету, не изменяя столбцы базы данных. Это звучит разумно?

• Должен ли я хранить всю информацию в одной и той же базе данных, но в разных таблицах или разных сущностях (врагах и комнатах) в разных базах данных.

• Я знаю, что это будет червь, но каковы некоторые предложения для хорошей базы данных? Является ли MySQL хорошим выбором?

Answer 1

• Этот метод называется модель значения атрибута объекта . Обычно предпочтительно иметь схему БД, которая отражает структуру объектов, и обновлять схему при изменении структуры вашего объекта. Такую строгую схему проще запрашивать, а также легче убедиться в правильности данных на уровне базы данных.
• Это одна база данных с несколькими таблицами.
• Если вам нужен сервер базы данных, я рекомендую PostgreSQL. У MySQL есть некоторые преимущества, такие как легкая репликация, но с PostgreSQL работать лучше. Если вы хотите что-то меньшее, которое работает непосредственно с приложением, SQLite - хорошая встроенная база данных.

Answer 2

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

2) Хранить информацию в разных таблицах.

Как пример:

• T1: номера

• T2: общие свойства комнаты (применимо к каждой комнате), с рядом на ** комнату *

• T3: уникальные свойства комнаты (применимо к меньшинству комнат, с числом на свойство на комнату - это позволяет легко добавлять пользовательские свойства без добавления новых столбцов

• T4: связи между номерами и номерами

  Наличие T2 и T3 важно, поскольку оно позволяет комбинировать эффективность и скорость идеи строки на комнату, где это применимо, с гибкостью / обслуживаемостью / экономией места для атрибута на сущность на строку (или объекта / атрибута). / значение как IIRC это называется в причудливых терминах) схема

Хорошая дискуссия здесь

3) Разумная реализация, попробуйте написать что-нибудь повторно используемое, например. иметь общие методы «Get_room», которые под доступом к БД - = в идеале через транзакционный SQL или ANSI SQL, так что вы можете безболезненно пережить изменение серверной части БД.

Для начальной работы вы можете использовать SQLite. Дешевый, простой и совместимый с SQL (лучшее свойство из всех). Установка практически ничего не значит, управление БД может осуществляться с помощью бесплатных инструментов или даже плагина FireFox IIRC (все хранилища данных FireFox 3 - история, закладки, места и т. Д. - все это базы данных SQLite).

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

Answer 3

Хранение всего объекта (сериализованного / закодированного) в качестве значения в базе данных плохо подходит для запросов - я уверен, что некоторые запросы в вашей грязи НЕ ДОЛЖНЫ знать 100% атрибутов, или могут получить список объектов путем значение атрибутов.

Answer 4

кажется, что это больше работа для базы данных

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

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

Вы можете использовать «объектно-реляционный маппер», который может упростить для вас многое из этого. Примеры в Python включают SQLObject , SQLAlchemy и Autumn . Они скрывают много сложностей для вас, но в результате могут скрыть и некоторые важные детали. Я бы рекомендовал использовать базу данных напрямую, пока вы не ознакомитесь с ней, и рассмотрите возможность использования ORM в будущем.

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

К сожалению, нет - если вы это сделаете, вы потеряете 99% возможностей базы данных и эффективно используете ее как прославленное хранилище данных. Однако, если вам не нужны вышеупомянутые возможности базы данных, это правильный маршрут, если вы используете правильный инструмент для работы. Для этой цели стоит обратить внимание на стандартный полка .

Должен ли я хранить всю информацию в та же база данных, но в разных таблицы или разные объекты (враги и комнаты) в разных базах данных.

Одна база данных. Одна таблица в базе данных на тип объекта. Это типичный подход при использовании реляционной базы данных (например, MySQL, SQL Server, SQLite и т. Д.).

Я знаю, что это будет червячная банка, но каковы некоторые предложения для хорошая база данных? Является ли MySQL хорошим выбором?

Я бы посоветовал придерживаться sqlite, пока вы не познакомитесь с SQL. В противном случае, MySQL является разумным выбором для бесплатной игровой базы данных, как и PostGreSQL.

Answer 5

Одна база данных. Каждая таблица базы данных должна ссылаться на фактический объект данных.

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

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

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