请问反范式编程适合用ef nh等orm吗？

[kamen]

之前被数据库的范式坑过好多回，这次的新项目我想各个数据表之间不建关系，直接冗余字段，这样的设计适合用orm吗？

[xuzuning]

ORM 最适合用于单表操作这种傻傻的事情 关联操作这种需要智慧的事情，ORM 做不好

[正怒月神]

我个人觉得，既然你不想用 主外键关系，那么为何还要用ef和nh？ 至少ef里，没有主外键，貌似Include就无法使用。

[娃都会打酱油了]

范式就是必要时遵守，看情况打破 而且orm才不管你有没有遵守范式呢 现在的数据库被越来越多的人认为就该做数据库存储，其它业务逻辑啥的在数据库中应尽可能的少，存储过程可以的话尽可能的少，触发器直接就干掉，游标不许用

[showjim]

范式是单纯的基于关系数据库来考虑问题的，它的出发点是让数据库解决所有问题。 ORM是基于对象模型来考虑问题的，它的出发点应该是让程序解决所有问题。 当然两者之间可能存在中间态，我觉得它们都是两头不讨好，比较痛苦。 对于基于缓存的ORM而言，数据是否冗余要看具体的缓存策略与查询需求。

[月影]

如果冗余太多，当你做更新的时候，你就崩溃了。

[Poopaye]

决定这个不是通常看2点么？ 1、你是不是处女座 2、你有多少钱

[我纯洁全身都纯洁]

不知道，我个人习惯是建立关系，符合三范式。 我们现在的项目，数据库不建立关系，使用真删除，结果导致数据删除之后影响到其他表的数据（程序没做处理），几乎每张表之间都有大量相同字段，修改字段的时候漏掉修改一个就不知道到底那个是正确的。（大部分原因是开发人员水平问题）

[圣殿骑士18]

引用 7 楼 hanjun0612 的回复:

我个人觉得，既然你不想用 主外键关系，那么为何还要用ef和nh？ 至少ef里，没有主外键，貌似Include就无法使用。

include不是ef的全部，而且这东西是笛卡尔积访问，冗余数据量大，占用带宽。如果是internet上那对响应速度的影响是比较大的。 我建议是少用include 我现在用ef，没有用外键，多表关联直接用linq，觉得很灵活很好。

[小灰狼]

引用 2 楼 sp1234 的回复:

你干脆别建什么“各个数据表”，只建一个数据表呗。如果你建了多个数据表，那么当你的数据模型稍微复杂一点时，一堆的互相不一致的数据层出不穷、指数级快速出现，你如何解释垃圾？ 这跟什么 orm 没有多大关系。连数据正确性都不能保证，谈不上技术。

没错没错 数据库范式增加了很多约束，约束是根据业务逻辑制订的，违反约束其本质就是违反业务逻辑 如果只为了开发方便，让程序快点编译通过、测试通过而忽略那些约束，还不如直接跳过软件测试，只要你的程序编译通过就直接交付。以后出了问题怎么办？管它呢，到时再说吧！ 一个词评价，驼鸟！

[小灰狼]

引用 4 楼 daixf_csdn 的回复:

我也不喜欢高范式，我的个人喜好是，不用外键关系，不用触发器。 尤其是外键关系，它给开发中的数据库维护带来不便，性能也是问题。 但对于冗余，我还是觉得应该尽量消除。

在开发阶段，建立足够的数据库约束（不仅仅是外键约束）能够把很多程序中的逻辑处理问题及时地在开发阶段暴露出来，最终减少交付的产品中存在的隐患 如果问题遗留在交付的软件产品中，将来进行维护会更麻烦。如果仅仅是单纯的把软件中的 bug 修复可能会很简单，但是要把之前不合理的数据逻辑纠正过来，这要花的时间、承担的风险会更麻烦。

[娃都会打酱油了]

范式没有定义主外键的事！ 第一范式：每个字段意义唯一 第二范式：每行都有唯一性标志 第三范围：每个字段不能由自身所在表的其它字段推导出

[IE11下面经常卡到爆]

用外键约束，但可以不用它的级联增删改，完全用程序控制。既能利用外键在关联查询时的优势，又灵活 不管是db还是code first这个都不是事儿

[IE11下面经常卡到爆]

引用 17 楼 daixf_csdn 的回复:

[quote=引用 7 楼 hanjun0612 的回复:] 我个人觉得，既然你不想用 主外键关系，那么为何还要用ef和nh？ 至少ef里，没有主外键，貌似Include就无法使用。

include不是ef的全部，而且这东西是笛卡尔积访问，冗余数据量大，占用带宽。如果是internet上那对响应速度的影响是比较大的。 我建议是少用include 我现在用ef，没有用外键，多表关联直接用linq，觉得很灵活很好。[/quote] 你想多了，只有full join才会全关联，大多数时候还是inner join或者out join

[正怒月神]

引用 17 楼 daixf_csdn 的回复:

[quote=引用 7 楼 hanjun0612 的回复:] 我个人觉得，既然你不想用 主外键关系，那么为何还要用ef和nh？ 至少ef里，没有主外键，貌似Include就无法使用。

include不是ef的全部，而且这东西是笛卡尔积访问，冗余数据量大，占用带宽。如果是internet上那对响应速度的影响是比较大的。 我建议是少用include 我现在用ef，没有用外键，多表关联直接用linq，觉得很灵活很好。[/quote] include只是一个left join。 另外如果需要查询关联实体，不使用主外键，而通过Linq查询起来比较麻烦，感觉匿名对象不方便传递。

[kamen]

引用 2 楼 sp1234 的回复:

你干脆别建什么“各个数据表”，只建一个数据表呗。如果你建了多个数据表，那么当你的数据模型稍微复杂一点时，一堆的互相不一致的数据层出不穷、指数级快速出现，你如何解释垃圾？ 这跟什么 orm 没有多大关系。连数据正确性都不能保证，谈不上技术。

按你这么说，nosql谈不上技术？nosql貌似提倡冗余的。

[kamen]

引用 18 楼 hemowolf 的回复:

[quote=引用 2 楼 sp1234 的回复:] 你干脆别建什么“各个数据表”，只建一个数据表呗。如果你建了多个数据表，那么当你的数据模型稍微复杂一点时，一堆的互相不一致的数据层出不穷、指数级快速出现，你如何解释垃圾？ 这跟什么 orm 没有多大关系。连数据正确性都不能保证，谈不上技术。

没错没错 数据库范式增加了很多约束，约束是根据业务逻辑制订的，违反约束其本质就是违反业务逻辑 如果只为了开发方便，让程序快点编译通过、测试通过而忽略那些约束，还不如直接跳过软件测试，只要你的程序编译通过就直接交付。以后出了问题怎么办？管它呢，到时再说吧！ 一个词评价，驼鸟！[/quote] 业务逻辑不能用在程序里边控制？貌似用程序控制更灵活些？我这用惯了范式的人倒觉得反范式的写法更有技术性，需要关注的层面更多。当然应用层的代码量也会大量增加。

[a8332496]

看局势，而议。。。

[小灰狼]

引用 27 楼 iFitch 的回复:

[quote=引用 18 楼 hemowolf 的回复:] [quote=引用 2 楼 sp1234 的回复:] 你干脆别建什么“各个数据表”，只建一个数据表呗。如果你建了多个数据表，那么当你的数据模型稍微复杂一点时，一堆的互相不一致的数据层出不穷、指数级快速出现，你如何解释垃圾？ 这跟什么 orm 没有多大关系。连数据正确性都不能保证，谈不上技术。

没错没错 数据库范式增加了很多约束，约束是根据业务逻辑制订的，违反约束其本质就是违反业务逻辑 如果只为了开发方便，让程序快点编译通过、测试通过而忽略那些约束，还不如直接跳过软件测试，只要你的程序编译通过就直接交付。以后出了问题怎么办？管它呢，到时再说吧！ 一个词评价，驼鸟！[/quote] 业务逻辑不能用在程序里边控制？貌似用程序控制更灵活些？我这用惯了范式的人倒觉得反范式的写法更有技术性，需要关注的层面更多。当然应用层的代码量也会大量增加。 [/quote] 业务逻辑在程序里当然可以控制，但是那要经过很多测试，很有可能在测试时会遗漏 这也不是灵活性的问题，无论是在开发阶段还是在正式使用阶段，通过数据库约束给软件产品中的数据关系加上一层保险 我追求的不是项目的技术性，而是尽可能把问题简单化，减少工作量，减少出错的机率 数据库加上约束，虽然在开发阶段让人很烦，但它可以让开发人员及时发现开发中的逻辑错误（因为违反数据库约束其实就是违反业务逻辑）；在运行阶段，如果因为测试时遗漏了某个环节而导致程序运行不下去，客户会抱怨软件暂时无法使用，但我认为这至少比客户勉强运行软件后得到一个逻辑错误的结果要好，并且后期为了修复数据库中的逻辑错误，你要作出大量的分析工作，那是相当相当头疼的。

[bluedoctor]

楼主这也是一种可行的方式，但跟ORM没有关系的，也即是说，数据库表没有关系，但是实体类可以有关系，这个可能需要你的ORM能够支持。 可以试试SOD框架，它的ORM功能跟数据库的映射是最松散的。

[qq_35376354]

div.img:hover {
    border: 1px solid #777;
}