不在此数据库中使用规范化表是不是很糟糕？

Question

我最近了解了我的信息学课程中的规范化,并且我正在开发一个使用SQLite作为后端数据库的多人游戏.

有关它的一些信息:

简化的结构看起来有点像下面这样:

 player_id |  level | exp  | money | inventory
---------------------------------------------------------
    1      |    3   | 120  | 400   | {item a; item b; item c}

好的.如您所见,我将以字符串形式将表/数组存储在"inventory"列中.这违反了规范化.

但问题是:为玩家的库存制作额外的桌子对我来说只是一个缺点!

• 我访问数据库的唯一点是:
  • 当玩家加入游戏并加载他的个人资料时
  • 保存球员的个人资料时

当玩家加入时,我从数据库加载他的数据并将其存储在内存中.保存播放器时,我每隔五分钟就会写一次DB.所以我的脚本中实际上只有很少的SQL查询.

如果我在加载时使用了额外的表格,我将不得不:

• 执行性能和可能更多数据密集型查询以从库存表中获取属于玩家X的所有项目
• 浏览结果并将其转换为表格以便存储在内存中

保存时:

• 从库存表中删除属于玩家X的所有物品(玩家可能已经丢弃/出售了一些物品？)
• 浏览表格并对玩家拥有的每个项目执行查询

如果我将所有玩家数据保存在一个表中:

• 我只有一个用于保存和加载的查询
• 一切都会在一个地方
• 在我的脚本中,我只需要在加载和保存时(de)序列化表

我现在应该怎么做？

我的论点和情况是否有理由反对正常化？

Answer 1

您是说您认为从"库存" 中解析字符串不需要任何时间或精力吗？因为您需要执行从子表中存储/检索库存项目所需的一切,所以您需要对此字符串执行操作,并且使用该字符串您没有任何数据库工具来帮助您执行此操作.

此外,如果您有一个单独的库存项子表,您可以实时添加和删除项目,这意味着如果应用程序崩溃或用户断开连接,它们不会丢失任何内容.

Answer 2

有很多可能的答案，但最适合您的就是您要选择的一个。请记住，您的选择可能需要随着时间的推移而改变。

如果您需要保留的数据量很小（即：适合单个表行）并且您只需要很少更新该数据，并且您没有任何理由关心该数据的子集，那么您的方法说得通。随着时间的推移，您的玩家获得更多物品，并且您向游戏添加更多个性化内容，您可能会开始突破 SQLite 的限制，并且需要改进您的设计。如果您发现需要能够查询物品列表以确定哪些玩家拥有哪些物品，则需要改进您的设计。

人们普遍认为尽早建立正确的数据架构是个好主意，但是今天坐在会议上试图猜测 5 到 10 年后将如何使用软件是没有意义的。最好得到一个满足今年需求的设计，然后计划一年后再次重新评估该设计。