如何选择如何存储数据？

给一个人一条鱼，你就喂他一天。教一个人钓鱼，你就养活他一辈子。 - 中国谚语

我可以问一下我应该为实际项目使用哪种数据存储，但是我想学习钓鱼，所以我不必在每次开始新项目时都要求钓鱼。

因此，直到我使用两种方法在我的非游戏项目上存储数据：XML文件和关系数据库。我知道还有NoSQL类型的其他数据库。但是我不知道是否有更多选择可供选择，或者首先是如何选择，除了随意选择一个。

因此，问题如下：如何为游戏项目选择数据存储类型？

在选择时，我会对以下标准感兴趣：

• 项目的大小。
• 游戏所针对的平台以及所使用的开发平台。
• 数据结构的复杂性。
• 在许多项目之间增加了数据的可移植性。
• Added2 Silmutaneous使用不同之间的项目数据。（即用户数据）
• 添加了应该多长时间访问一次数据
• 为同一应用程序添加了多种类型的数据
• 带有多个数据存储的Added2配置。
• 在决定使用什么时，您认为还有其他要点。

编辑我知道关于使用XML / JSON / Text或数据库存储游戏内容会更好吗？，但认为它不能完全解决我的观点。现在，如果我错了，我将很高兴以自己的方式看到错误。

EDIT2添加了一些我认为相关的观点。此外，除了平面文件存储和关系数据库之外，我想听听还有哪些其他可用的选择。例如，非关系数据库呢？在前面提到的其他选项上使用这样的数据库是否有意义？

由于种类繁多，您的问题确实很广泛，但这是专业软件开发人员的观点。

您提供了要用于确定使用哪种数据持久性机制的条件列表。那些是：

• 项目的大小。
• 游戏所针对的平台。
• 数据结构的复杂性。
• 数据在许多项目中的可移植性。
• 应该多久访问一次数据
• 同一应用程序的多种数据类型
• 在决定使用什么时，您认为还有其他要点。

首先，我们需要确定哪些选项可供我们使用。由于您没有指定语言或技术，因此很难准确地说出，但是您可能正在尝试在XML和关系数据库存储之间做出决定。

一个重要的区别是，XML与其说是序列化技术，还不如说是一种存储机制。这是一种表示游戏内存结构的方法。鉴于此，您实际上是在谈论平面文件与关系数据库存储。这些不是唯一的选择，但它们是最常见的，因此我将使用它们。

对于平面文件：

• XML格式
• JSON格式
• YAML
• XAML
• 纯文本

对于数据库：

• SQL服务器
• 的MySQL
• DB2
• 甲骨文
• 还有很多

编辑：您询问了文件和关系数据库之外的其他类型的机制。我经常看到的唯一其他值得注意的数据库类型是“伯克利式”数据库，这些数据库本质上是基于键值的。它们倾向于使用B树来构造数据，因此查找速度很快。这些非常适合配置/设置查找，您可以在其中确切地知道所需的内容（例如，将“ Level 1”的所有遥测数据提供给我）。

现在我们已经掌握了所有基础知识，让我们谈谈您的一些标准。

项目的大小。

有些人可能会不同意，但是项目的规模并不一定会对数据持久性机制产生巨大影响。您将需要构建一个可重用的函数库，该函数库可以从所需的任何机制存储/加载数据。我什至建议您实现一个抽象层（查看Adapter模式），以便您可以根据需要轻松更改持久性机制。

话虽如此，对于小型项目，在文件系统上使用XML可能会很好地工作，但是您将需要解决一些安全性问题（即加密），以便播放器无法随意更改数据。

游戏所针对的平台。

平台也不是一个大问题。您应该比目标平台更关心您的开发平台。这样做的原因是，某些语言比其他类型的语言能更好地处理某些类型的标记或数据库。并不是说您几乎不能以任何一种语言使用以上任何一种方法，但是有时最好使用可用的支持工具。任何平台都将支持平面文件并解析XML，但是在移动平台上，如果可能，您可能需要考虑二进制序列化，或者至少优化XML进行存储。

数据结构的复杂性。

这有点棘手。关系数据库非常适合……存储实体及其关系。与使用文件系统上的文件相比，使用关系存储库执行结构的能力更好。考虑实体之间的关系类型以及更改它们或查找相关实体的频率。对于极其复杂的结构，我建议您走数据库路线。

数据在许多项目中的可移植性。

当涉及可移植性时，您应该考虑这样一个事实，即数据库自然比文件更重。有安装和配置开销，不同的数据库可用于不同的平台，等等。SQLite是解决此问题的不错方法。但是，在可移植性方面，您可能会更轻松地使用基于文件的解决方案（例如XML）。

编辑：在您的评论之一中提到了有关可移植性的其他一些问题。最终，您不希望您的数据与任何产品或文件类型紧密耦合。最终最好是以某种抽象格式（制表符分隔的文件，XML等）存储股票数据（级别，敌人等），您可以在编译或加载时轻松地分析并存储在数据库/文件系统中时间。这意味着您可以随心所欲地换出存储机制，而只需重写解析部分。

应该多久访问一次数据

除非您具有某种缓存机制，否则大量数据访问意味着大量I / O。数据库将结构保留在内存中，非常适合数据操作和检索。如果您确实要持续地持久存储数据，则可能要坚持使用数据库。

同一应用程序的多种数据类型

卷当然是要考虑的问题，但是除非要谈论持久存储成千上万个对象，否则文件系统仍然可以作为解决方案。

游戏类型

您正在构建的游戏类型可能会对您选择的平台产生巨大影响。是的，对于大多数仅客户端的单人游戏，使用基于压缩或加密文件系统的解决方案就可以了。但是，如果您谈论的是带有在线组件的游戏，那将是疯狂的。走数据库路线，省去自己的头痛。让服务器使用后端群集管理所有数据。

希望其中一些反馈有所帮助。这绝不是完全全面的，最终的决定取决于您，但是我的评论应该给您一些思考的东西。

编辑：在某些时候采取混合方法很有意义。例如，假设您正在开发MMORPG。在客户端，您可能将有关其他播放器的缓存数据存储在非关系数据库中（如上所述）。在服务器端，您将所有游戏数据存储在关系数据库中以持久保存。然后再次在客户端，您可能会将日志数据，配置数据等存储在XML /平面文件中，以便于访问。

另一位发布者还提到，有时即使将要存储的生产数据存储在数据库中，也可以使用平面文件进行开发，这很不错...从混合中删除另一种产品会更容易。

最近，我发现自己受限于添加到关系数据库的严格性/困难性。我很想探索基于文档的数据库（例如，couchdb），因为它们似乎非常适合游戏，状态和灵活性。但是，为一个小型项目设置多种数据库类型实际上并不实际。结果，我建立了一个类似于只在数据库的某些字段中使用二进制blob字段的黑客。

我正在做的是在数据库中使用json编码的数据，以及将数据转换为json并在需要时将其转出的包装器。因此，基本字符配置文件在数据库中可能如下所示：

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

Json在数据库中仍然可读性很好，因此，如果您正在使用sql进行操作，有时甚至也直接访问数据库，则可以手动修改它。

现在，所有这些都是hack，我不建议复制它，但这是总的要点： 不要仅依赖一个系统。 使用关系数据库并伪装系统。或者使用两种不同类型的数据存储系统（例如，平面文件和关系数据库？），以便您可以从这两者中获得最大的收益。无论人们提出什么建议，或者使用哪种系统，都将发现在哪种情况下另一种方法会更好地工作，因此请准备添加替代方法，并查看将您带到何处。

在RTS基因中，游戏数据已存储在文件中。

单位和属性已存储在INI或XML文件或其他基于文本的格式中，并且模型已混合使用二进制或什至基于文本的格式以及纹理和声音以及其他主流格式的媒体。有时它是放在经过粗略加密的容器中的-想到了Westwood的混合格式。但这主要是混淆-如果您查看它们的内部，它们只是易于处理格式的普通文件。

随着在线游戏的出现，在Internet上在安装后配置游戏数据已变得越来越普遍，尽管通常仍将其存储在文件系统中。

为什么要使用一种数据存储方式？

在大多数情况下，发布给全世界的游戏并不需要开发过程中所需的数据存储功能。

以下是一些发行/开发要求的比较：

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

然后，理想情况下，您将定义数据加载模块的接口，然后创建多个版本，每个版本都针对特定需求进行了量身定制。

在我多年从事的一个项目中，从CD上加载电平数据花费的时间太长了（对于HD来说也不是很好）。因此，我提出了以下建议。我有三种加载级别数据的方法：

1. 正常加载-用于资产更改时的开发时间
2. 预发布-有效地将普通数据转换为快速加载数据的方法
3. 发布-仅快速数据（不可编辑）

这样可以将加载时间从几分钟减少到几秒钟。