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

Question

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

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

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

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

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

Answer 1

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

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

В качестве примера:

• T1:Комнаты

• Т2:Общие свойства помещения (применимы к каждому помещению), со строкой для каждого ** помещения*

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

• Т4:Соединения между комнатами

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

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

3) С точки зрения реализации, попробуйте написать что-нибудь пригодное для повторного использования, напримериспользуйте общие методы "Get_room", которые позволяют получить доступ к DB -= в идеале через transact SQL или ANSI SQL, чтобы вы могли безболезненно перенести изменение серверной части DB.

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

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

Answer 2

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

Answer 3

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

Answer 4

похоже, это больше похоже на работу для базы данных

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

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

Возможно, вы захотите использовать "объектно-реляционный картограф", который может многое упростить для вас.Примеры в Python включают Квадратный объект, Sql - алхимия, и Осень.Они скрывают для вас множество сложностей, но в результате могут скрыть и некоторые важные детали.Я бы рекомендовал использовать базу данных напрямую, пока вы не познакомитесь с ней поближе, и рассмотреть возможность использования ORM в будущем.

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

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

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

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

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

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

Answer 5

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

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

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

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