复杂类型字段

Question

我想在我的用户表中分隔联系人信息，我正在考虑两种方法。 首先是创建一个新表，然后我的User表通过外键引用该表。

或者通过向<% item.category_item_values.each do |category_item_value| %> <%= category_item_value.value %> <% end %> 字段添加User注释来制作属于[ComplexType]表的复杂类型。

这是Address类，只是一个例子：

Address

你建议我做什么？哪种方式更好？

Answer 1

对此没有完美的选择，这取决于多样性：如果用户有多个地址，那么你需要使用外键选项，如果用户只有一个地址，你可以添加地址字段到用户字段（简单）或使用[ComplexType]

Answer 2

你的第一个（单独的表）选择更好，因为单个用户有多个联系人记录，那么最好通过外部引用在单独的表中处理它。

最好更改其联系信息，意味着永久地址，邮政地址，常驻联系人号码，自我联系号码等等，您可以在单独的表格中轻松更新此信息，

这是数据库中规范化的好习惯

Answer 3

如果你问一个干净的编码员这个问题，那么他会用两个实体/类SRP回答你 http://www.oodesign.com/single-responsibility-principle.html

如果您对数据库delevoper提出同样的问题，那么他的回答将是没有联接使用复杂类型。

作为开发人员，我发现复杂类型有一些限制，我永远不会使用它们。

在这里，我将从http://weblogs.asp.net/manavi/associations-in-ef-4-1-code-first-part-2-complex-types复制复杂类型的优点和缺点：

映射为复杂类型的类有三个重要的限制：

• 共享参考不可能： 地址复杂类型没有自己的数据库标识（主键），因此除了包含User的实例之外的任何对象都不能引用它（例如，也需要引用相同用户地址的Shipping类，不能这样做。）

• 没有优雅的方式代表空参考： 正如我们所看到的，没有优雅的方法来表示对地址的空引用。从数据库读取时，即使复杂类型的所有映射列中的值都为空，EF Code First也始终初始化Address对象。

• 不可能延迟加载复杂类型： 请注意，当加载包含复杂对象的实体实例时，EF始终会立即初始化复杂类型的属性值。 EF不支持复杂类型的延迟加载（如果您希望对实体的标量属性进行延迟加载，则也存在相同的限制）。当我们必须处理可能较大的值（例如，Address复杂类型上的byte []类型的属性已经映射到Users表上的VARBINARY列并且保存Address所描述的位置的图像时，这是不方便的。 ）。

最佳实践，您可以在上面的给定链接中阅读。