有人问过类似的问题，但没有回答。 How to store value objects in a relational database?如何在关系数据库中存储对象？
这是一个示例情况，我的问题发挥作用。假设有一个'用户'表，每个用户需要存储他们的位置。他们的位置基本上只有3个坐标：x，y，z。
但是，我不知道我应该如何去做这件事。我可以将3个整数字段添加到名为'x，y，z'的'用户'行。
或者，我可以添加一个'位置'字符串字段到用户行，然后只要序列化和反序列化每当我获取/保存用户的位置。
或者，我可以创建一个'locations'表，它具有一个auto-inc主键id，它将用作'用户'位置数据库的外键，它将有4个字段：'id'， 'x'，'y'，'z'。
那么，哪一个最好？也许有一个答案，我没有看到更好的？谢谢。
鉴于所有情况都不同，有时候以微妙的方式，通常情况下并不是“最好的”。
不过，如果你正在寻找一个全面的“最佳实践”设计一般的东西时，我会朝着这个瘦：
做最简单的事情可能的，只有在需要的时候增加了复杂性。
为此，我想象Users表中的三个整数列是有意义的，而且非常简单。你需要需要将数据序列化成字符串吗？毕竟，数据本身不是一个字符串。这是一组数字值。这可能会使其他事情变得不必要地困难，不是吗？数据是否需要位于具有自己标识符的单独表格中？毕竟，它本身并不是一个实体，而只是一个描述User的数据点。
除非有令人信服的理由去做更复杂的事情，否则保持简单。
在我看来，标准化会更好。
当然，没有最好的方式，因为这取决于工作负载（你的查询，你将针对这些表中运行），数据本身，等等
例如，你会在阅读和更新x，y和za很多，如果你必须从每一行进出的字符串中解析出它们，这可能会有所帮助，例如，你是否需要一个单独的位置集合，以这种方式一个不同的表会帮助，等等...
我会使用你的第3个选项，考虑到用户需要存储更多的数据，而不仅仅是x，y，z。如果不是我会改变该表的名称...
我的理由：
数据库的可读性：¿什么代表用户X Y Z'什么代表一个位置的x y z？最后一个听起来更直观的
如果100个用户可在同一地点进行的，你只需要那些100级的用户指向该位置A.
如果你想更多的数据添加到该位置（比如address，lat lng，wheater ...）只需要编辑添加列的表格位置，然后编辑一行（而不是100）。
您可以将位置上存储的所有数据用于其他目的。如果您最近还需要存储像建筑，车辆等其他情况下..你拥有所有的结构准备好，甚至你当前的数据是可用的
Brieffing我找到最后一个更可读，可扩展性和灵活性比另外两个。但这取决于你的项目的范围我猜
几乎从来没有真正的“最好”。 –
_“...但它没有回答”_：嗯，[现在是]（http://stackoverflow.com/questions/15650898/how-to-store-value-objects-in-a-relational -database/19665483＃19665483）！ ;） – geomagas