之前有人问过类似的问题，但没有回答。如何将值对象存储在关系数据库中？
这是我的问题发挥作用的示例情况。假设有一个“用户”表，每个用户都需要存储他们的位置。它们的位置基本上只有 3 个坐标：x、y、z。
但是，我不确定我应该怎么做。我可以在名为“x、y、z”的“用户”行中添加 3 个整数字段。
或者，我可以在用户行中添加一个“位置”字符串字段，然后在获取/保存用户位置时简单地序列化和反序列化。
或者，我可以创建一个 'locations' 表，它有一个 auto-inc 主键 id，将用作 'users' 位置数据库的外键，它有 4 个字段：'id'、'x'、 'y'，'z'。
那么，哪一个最好呢？也许有一个我没有看到更好的答案？谢谢。
鉴于所有场景都不同，有时以微妙的方式，通常没有“最佳”。
但是，如果您在设计一般事物时正在寻找整体“最佳实践”，我倾向于这样做：
尽可能做最简单的事情，只在需要时增加复杂性。
为此，我认为表中的三个整数列Users是有意义的并且非常简单。您需要将数据序列化为字符串吗？毕竟，数据本身不是字符串。它是一组数值。这可能会使其他事情变得不必要地困难，不是吗？数据是否需要位于具有自己标识符的单独表中？毕竟，它本身并不是一个真正的实体，而只是一个描述User.
除非有令人信服的理由去做更复杂的事情，否则请保持简单。
考虑到用户需要存储比 x、y、z 更多的数据，我会使用您的第 3 个选项。如果不是，我会更改该表的名称...
我的理由：
数据库的可读性：¿什么代表用户的 xyz？什么代表位置的 xyz？最后一个听起来更直观
如果 100 个用户位于同一位置 A，您只需将这 100 个用户指向该位置 A。
如果您想向该位置 A 添加更多数据（例如地址、纬度、经纬度、小麦...），只需编辑表位置添加列并只需编辑一行（而不是 100 行）。
您可以将存储在位置上的所有数据用于其他目的。如果您最近还需要存储其他实例，如建筑物、车辆等。您已准备好所有结构，甚至您当前的数据也可用
Briefing 我发现最后一个比其他两个更具可读性、可扩展性和灵活性。但这取决于你的项目范围，我猜
在我看来，标准化会更好。
当然，没有最好的方法，因为这取决于工作负载（您将对这些表运行的查询）、数据本身等等......
例如，您是否会读取和更新 x、y 和 za 批次，如果您必须为每一行进出的字符串解析它们，这可能会有所不同，例如，您是否需要一个单独的位置集合，这样让那些在不同的桌子上会有所帮助，等等......