Question

我用Java编写了一个数学游戏，并向一些beta测试者分发了一些副本。问题是我给他们的版本是通过对象序列化保存GameData，我发现它主要用于通过网络发送对象，或者在这种情况下，GameData的ArrayLists。它不是持久的;这就是关系数据库的用途。知道这一点，我想知道在beta测试仪的机器上创建一个数据库（并重写游戏），或者继续使用游戏的Object序列化版本，然后在它们准备就绪时检索它们会更好发送数据？

我的猜测是将他们的数据移动到在他们的计算机上创建的数据库，然后给他们数据库版本的游戏。这样，数据可以持久化并且更容易操作。让我远离这个想法的是我将如何将他们的数据库写入我的（未来）的问题？

Answer 1

虽然比较少见，但仍有许多应用程序使用序列化来存储和检索对象。这样做并不是错误，只是有点不寻常。 如果它适合你，坚持下去因为DB是一个重量级的解决方案。你发现的关于序列化的内容只是一种观点，而且形成了一个不合理的观点。

Answer 2

在使用嵌入式数据库方面，需要考虑的两个选项是SQLite和HyperSQL。但是，序列化也是一种选择，在我看来，如果你已经实现了它，它应该是你的默认选项。一些注意事项：

通过序列化，您通常需要检索整个对象，如果您有一个包含数十个字段的对象并且您只想读取其中一个字段，那么这个对象会很慢。如果您正在进行这样的查询，请使用数据库。我怀疑你只是在启动时读取所有序列化对象，并在关机时将它们序列化回磁盘，在这种情况下，没有理由使用数据库而不是序列化。
Java的默认序列化机制相当慢。您可能需要考虑另一种序列化机制，例如Kryo或Jackson，但前提是您对程序的序列化性能不满意。

Answer 3

如果不知道自己持续存在的原因和原因，很难就最佳技术选择提出建议。

如果状态只是游戏状态的快照（即保存文件）或最佳分数＆＃34;表，那么你不需要一个数据库。使用JSON，XML或...序列化Java对象序列化就足够了。
如果状态需要以递增方式读取或更新，或与其他应用程序...或其他计算机上的用户共享......那么数据库更合适。

如果要求包括增量更改等，则序列化机制会出现问题。您最终会在序列化的顶部构建类似数据库的层。

至于你是否应该坚持使用Java序列化......或者切换到JSON或XML或类似的东西：

对象序列化很简单，但如果更改要序列化的类，它可能很脆弱。这种脆弱性可以减轻，但它很混乱，你会失去简单性。（您需要编写自定义readObject和writeObject方法，这些方法知道如何阅读序列化对象的旧版本和＃34 ;.
JSON和XML有点复杂，但如果使用对象绑定机制，仍然相对简单。

值得注意的是，无论您做什么，对持久化对象类（或数据库模式）的更改都可能存在问题。这个问题没有简单的通用解决方案。

<强>更新

鉴于您在第一条评论中提供的其他信息（如下），您似乎不需要游戏本身的数据库。您所需要的只是能够读取和分析您的Beta测试人员为您提供的会话状态保存文件。实际上，它似乎并不像真正的应用程序需要能够读取文件。（但那还不清楚，因为你还没有说出这些文件的真正目的是什么......或者至少，不是整个目的是什么。）

值得注意的是，如果您的目标是调整问题集，那么您可能正在保存错误的信息。你真正需要做的是记录时间长度以及用户是否得到了正确或错误的答案以及每个问题的时间....您可能需要知道给出的实际答案是什么......这样您就可以发现用户的答案实际上是正确的并且您已经标记为＆＃34;它是错误的......反之亦然。

＆＃34;让我远离这个想法的是我将如何将他们的数据库写入我的（将来）的问题？＆＃34;

完全。如果你没有过早地分析＆＃34;数据，你不会有这个问题。

但忽略这一点，似乎一个简单的状态保存机制足以满足您（仍然假设 / 推断）保持个人记分板的要求最终用户。你的调整＆＃34;使用自定义日志文件可以更好地实现。在将数据库合并为应用程序本身的一部分时，我看不出任何价值。

Answer 4

我认为你正在进行java序列化，如果是这样，它没有任何问题。请注意它的局限性 - 不同版本的java可能无法检索文件。此外，如果更改班级，则无法检索以前保存的数据。

如果您决定改变，您可以查看Xml，JSon，Protocol Buffers，Thrift，Avro等以及数据库。

注意：

  Xml is builtin in to java 
  Java Db (Derby) is also in Java

其他序列化架构需要一个单独的库。

继续使用对象序列化还是使用数据库？

4 个答案: