数据库列中的CSVs不是个好主意？

Question

不久前，我开始意识到，我想通过CSV格式来掌握游戏玩家的技能。在球员的统计数据上，我制作了一个技能的变种，这些技能将被存储为CSV。(1、6、9、10等)我为每个技能(名称、效果)制作了一个带有附属统计数据的“技能”表，当需要查看它们具有哪些技能时，我所要做的就是查询单个列并使用PHP的str_getcsv()来查看某个技能是否存在，因为它将位于数组中。

然而，我的同事建议，一个高级系统就是让每个技能都成为每个玩家将使用的主“技能”表中的一个条目，并且每个技能都有一个玩家的ID外键。我只是查询这个表中的所有行，返回的将是它们的技能！

一开始我以为这不是很好，但似乎互联网不同意。我知道这不太容易搜索--但我从来没有想过要说：“玩家有x技能吗？”或者“给我看所有有这种技能的球员！”在最坏的情况下，如果我想要这样的数据，我只会为它做一个PHP，当然，这将是缓慢的。

但这看起来好像真的更快？！我很难找到一个难以回答的问题，超出了“是的，这是好的，正常的”。堆栈溢出能帮我吗？

编辑:谢谢，伙计们！我从来没意识到这有多糟。很抱歉被骗了，但相信我，我打的这些都是不检查的。:P

Answer 1

将逗号分隔的值放入数据库中的单个字段并不仅仅是一个坏主意，它是撒旦在数据库模型中表达的化身。

它无法准确地表示许多情况(在这种情况下，值包含一个逗号或CSV消费代码遇到问题的其他东西)，通常存在嵌套在其他值中的值问题，无法正确索引，无法在数据库连接中使用，难以删除，无法添加附加信息(在您的情况下，或技能级别)，无法参与关系完整性，不能强制执行类型约束，等等。名单几乎是无穷无尽的。

MySQL尤其如此，它具有非常方便的group_concat函数，在需要时可以方便地将这些数据表示为逗号分隔的字符串，同时仍然保持规范化数据库的全部功能和速度。

使用逗号分离方法没有任何好处，但却失去了可搜索性和性能。让撒旦支持你，让你的数据正常化。

Answer 2

嗯，有一些事情需要考虑，比如可缩放性。如果您需要添加/删除技能怎么办？重新命名一项技能怎么样？如果技能的数量增长到您领域的规模，会发生什么情况？为了适应这样的情况，必须重新调整场地的大小是很糟糕的做法。

可维护性呢？另一个开发人员能进来了解您所做的事情吗？如果同样的技能给玩家两次，会发生什么？

你同事的建议也不对。在这种情况下，您将有3个表。一个主玩家表、一个技能表和一个与两者都有关系的表，创建了许多到多个关系，允许单个技能与多个玩家相关联，以及许多具有相同技能的玩家。

Answer 3

因为数据库将索引内容(假设您使用索引)，所以搜索内容和获取所需内容将非常快。记住:数据库是为保存大量信息而设计的，而作为关系数据库的mysql之类的数据库是为关系创建的。

另一个问题是系统的可维护性。维护一个规范化的系统要容易得多。当你要移除或增加一项技能时，它会更容易。

当您要从数据库中获取有关播放机技能的信息时，您可以通过简单的连接轻松地获得与相关技能相关的信息。

我说:让数据库做它做的最好的-处理数据。让你的编程做它应该做的事情;)