這個表怎么設計呀

ccwlm741212

最初由 lodge 发布
[B]

哦, 看来偶的表达能力太低下了, [/B]

故事才刚刚开始呢

magicangel

最初由 lodge 发布
[B]
冗余的问题偶是不以为然的, 冗余是指相同的实体被多条记录重复使用, 当实体内容发生变化时, 就会产生数据整合性被破坏的问题. 这里, 所谓实体只是属性名和属性值的问题而已, 不存在可能破坏整合性的问题.
[/B]

我个人认为空值也是一种冗余。而且为了减少对已有查询或报表的维护和可能的影响，建议尽量少使用空值。对查询和数据修改语句进行规划，使空值的影响降到最小。冗余和完整性没有必然的联系。

yining

前面不是说了么？关键是要看用户的要求。允许空值的做法很简单，对象模型也比较好处理。但是主要的缺点是以后没有办法比较方便的扩充属性。这个对于成熟的企业（有相对固定的产品）不存在问题，或者问题很小。但是如果是一个变动比较大的行业，或者是新企业（产品还没有确定），则非常不适合。归根结底，设计是要看具体的需求的。

根据一般的经验，如果客户也不是很确定的话，选择属性名称和属性对应的列表的方式比空值要好一些。这样的应用有较大的弹性，即使日后用户需要更改属性，还是有余地的。

另外，多种产品属性的对齐也可以在业务逻辑中进行呀，不见的对速度的影响会有多大。但是这种方法可能会引起的麻烦是属性的查询必须通过属性名称，不太直观。

yining

最初由 magicangel 发布
[B]

我个人认为空值也是一种冗余。而且为了减少对已有查询或报表的维护和可能的影响，建议尽量少使用空值。对查询和数据修改语句进行规划，使空值的影响降到最小。冗余和完整性没有必然的联系。 [/B]

如果是相对固定的产品，允许空值的设计不应该对查询/维护产生太大影响吧？如果更多的情况下是只读操作的话，用LDAP吧。

magicangel

最初由 yining 发布
[B]

如果是相对固定的产品，允许空值的设计不应该对查询/维护产生太大影响吧？如果更多的情况下是只读操作的话，用LDAP吧。 [/B]

我引用的是微软的官方原话。

magicangel

这段：

而且为了减少对已有查询或报表的维护和可能的影响，建议尽量少使用空值。对查询和数据修改语句进行规划，使空值的影响降到最小。