您能为我的数据库设置提供一些建议吗？
我正在用Python开发一个MUD（多用户地下城），现在我需要添加一些房间、敌人、物品等。我可以对所有这些进行硬编码，但看起来这是这样的更多的是数据库的工作。
但是，我以前从未真正做过任何数据库工作，所以我想知道您对如何设置它有什么建议吗？
- 我应该以什么格式存储数据？
- 我正在考虑在数据库中为每个实体存储一个 Dictionary 对象。通过这种方式，我可以简单地动态向数据库添加新属性，而无需更改数据库的列。听起来合理吗？
我是否应该将所有信息存储在同一个数据库中，但在不同的表或不同数据库中的不同实体（敌人和房间）中。
我知道这会是一大堆蠕虫，但是对于一个好的数据库有什么建议吗？ MySQL 是一个好的选择吗？
I'm working on a MUD (Multi User Dungeon) in Python and am just now getting around to the point where I need to add some rooms, enemies, items, etc. I could hardcode all this in, but it seems like this is more of a job for a database.
However, I've never really done any work with databases before so I was wondering if you have any advice on how to set this up?
- What format should I store the data in?
- I was thinking of storing a Dictionary object in the database for each entity. In htis way, I could then simply add new attributes to the database on the fly without altering the columns of the database. Does that sound reasonable?
Should I store all the information in the same database but in different tables or different entities (enemies and rooms) in different databases.
I know this will be a can of worms, but what are some suggestions for a good database? Is MySQL a good choice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
1) 几乎没有任何理由将同一应用程序的数据存储在不同的数据库中。除非您是财富 500 强规模的公司（好吧，我有点夸张）。
2）将信息存储在不同的表中。
例如：
T1：房间
T2：房间公共属性（适用于每个房间），每个**房间*一行
T3：房间独特属性（适用于少数房间，每个每个房间的属性 一行 - 这样可以轻松添加自定义属性，无需添加新列
拥有 T2 和 T3 非常重要，因为它可以让您将每房间行理念的效率和速度与每行属性（或对象/属性）的灵活性/可维护性/空间节省相结合/value 作为 IIRC，它被用奇特的术语称呼）模式
这里有很好的讨论
3）明智的实现，尝试编写一些可重用的东西，例如具有通用的“Get_room”方法，该方法在底层访问数据库 - =理想情况通过事务 SQL 或 ANSI SQL，您可以轻松应对数据库后端的更改。
对于初始工作，您可以使用 SQLite。便宜、简单且兼容 SQL（所有属性中最好的）。安装几乎没什么，数据库管理可以通过免费软件工具甚至 FireFox 插件 IIRC 来完成（所有 FireFox 3 数据存储 - 历史记录、书签、位置等 - 都是 SQLite 数据库）。
对于后来的情况，可以选择 MySQL 或 Postgres（我不专业做任何一种，所以不能推荐）。 IIRC 在某个时候 Sybase 也有免费的个人数据库服务器，但不知道情况是否仍然如此。
1) There's almost never any reason to have data for the same application in different databases. Not unless you're a Fortune500 size company (OK, i'm exaggregating).
2) Store the info in different tables.
As an example:
T1: Rooms
T2: Room common properties (aplicable to every room), with a row per **room*
T3: Room unique properties (applicable to minority of rooms, with a row per property per room - thos makes it easy to add custom properties without adding new columns
T4: Room-Room connections
Having T2 AND T3 is important as it allows you to combine efficiency and speed of row-per-room idea where it's applicable with flexibility/maintanability/space saving of attribute-per-entity-per-row (or Object/attribute/value as IIRC it's called in fancy terms) schema
Good discussion is here
3) Implementation wise, try to write something re-usable, e.g. have generic "Get_room" methods, which underneath access the DB -= ideally via transact SQL or ANSI SQL so you can survive changing of DB back-end fairly painlessly.
For initial work, you can use SQLite. Cheap, easy and SQL compatible (the best property of all). Install is pretty much nothing, DB management can be done by freeware tools or even FireFox plugin IIRC (all of FireFox 3 data stores - history, bookmarks, places, etc... - are all SQLite databases).
For later, either MySQL or Postgres (I don't do either one professionally so can't recommend one). IIRC at some point Sybase had free personal db server as well, but no idea if that's still the case.
将整个对象（序列化/编码）作为值存储在数据库中不利于查询 - 我确信您的 mud 中的某些查询不需要知道 100% 的属性，或者可以通过值检索对象列表属性。
Storing an entire object (serialized/encoded) as a value in the database is bad for querying - I am sure that some queries in your mud will NOT need to know 100% of attributes, or may retrieve a list of object by a value of attributes.
确实如此，尽管“数据库”不一定意味着“关系数据库”。大多数现有的 MUD 将所有数据存储在内存中，并从以纯文本数据格式保存的平面文件中读取数据。我不一定推荐这条路线，只是指出传统数据库根本没有必要。如果您确实想走关系路线，最新版本的 Python 附带了 sqlite ，它是一个轻量级的嵌入式关系数据库，具有良好的SQL支持。
在代码中使用关系数据库可能会很尴尬。对游戏逻辑类的任何更改都可能需要对数据库进行并行更改，以及对读取和写入数据库的代码进行更改。因此，良好的规划会对您有很大帮助，但如果没有经验，很难规划出良好的数据库模式。至少首先规划您的实体类，然后围绕它构建数据库模式。阅读规范化数据库并理解其中的原理将会有所帮助。
您可能想要使用“对象关系映射器”，它可以为您简化很多工作。 Python 中的示例包括 SQLObject、SQLAlchemy 和秋季。这些为您隐藏了很多复杂性，但因此也隐藏了一些重要的细节。我建议您直接使用数据库，直到您更熟悉它，并考虑将来使用 ORM。
不幸的是不是 - 如果你这样做，你就浪费了数据库 99% 的功能，并且有效地将其用作美化的数据存储。但是，如果您不需要上述数据库功能，并且使用正确的工具来完成这项工作，那么这是一条有效的途径。为此，标准的 shelve 模块非常值得一看。
一个数据库。每个实体类型在数据库中都有一个表。这是使用关系数据库（例如 MySQL、SQL Server、SQLite 等）时的典型方法。
我建议坚持使用 sqlite，直到您更熟悉 SQL。除此之外，MySQL 是免费游戏数据库的合理选择，PostGreSQL 也是如此。
True, although 'database' doesn't have to mean 'relational database'. Most existing MUDs store all data in memory, and read it in from flat-file saved in a plain-text data format. I'm not necessarily recommending this route, just pointing out that a traditional database is by no means necessary. If you do want to go the relational route, recent versions of Python come with sqlite which is a lightweight embedded relational database with good SQL support.
Using relational databases with your code can be awkward. Any change to a game logic class can require a parallel change to the database, and changes to the code that read and write to the database. For this reason good planning will help you a lot, but it's hard to plan a good database schema without experience. At least get your entity classes planned first, then build a database schema around it. Reading up on normalizing a database and understanding the principles there will help.
You may want to use an 'object-relational mapper' which can simplify a lot of this for you. Examples in Python include SQLObject, SQLAlchemy, and Autumn. These hide a lot of the complexities for you, but as a result can hide some of the important details too. I'd recommend using the database directly until you are more familiar with it, and consider using an ORM in the future.
Unfortunately not - if you do that, you waste 99% of the capabilities of the database and are effectively using it as a glorified data store. However, if you don't need aforementioned database capabilities, this is a valid route if you use the right tool for the job. The standard shelve module is well worth looking at for this purpose.
One database. One table in the database per entity type. That's the typical approach when using a relational database (eg. MySQL, SQL Server, SQLite, etc).
I would advise sticking with sqlite until you're more familiar with SQL. Otherwise, MySQL is a reasonable choice for a free game database, as is PostGreSQL.
一个数据库。每个数据库表应该引用一个实际的数据对象。
例如，为所有物品、所有生物、所有角色类别、所有宝藏等创建一个表。
现在花一些时间弄清楚对象如何相互关联，因为这将影响您的数据库结构。例如，一个角色可以有多个角色类别吗？怪物可以有角色类别吗？怪物可以携带物品吗？房间里可以有多个怪物吗？
这看起来很迂腐，但是通过弄清楚哪些数据库对象“属于”哪些其他数据库对象，您可以尽早为自己省去很多麻烦。
One database. Each database table should refer to an actual data object.
For instance, create a table for all items, all creatures, all character classes, all treasures, etc.
Spend some time now and figure out how objects will relate to each other, as this will affect your database structure. For example, can a character have more than one character class? Can monsters have character classes? Can monsters carry items? Can rooms have more than one monster?
It seems pedantic, but you'll save yourself a whole lot of trouble early by figuring out what database objects "belong" to which other database objects.