有关ORM框架的新观点

1:A.B.C的业务场景下，n:n:n 允许业务从A，B，C，三个点的任何一个点进行切入

2、对于1:1 1:N N:N的场景，视图的观点是不恰当的，因为有外键关系在（如果在数据库中没有关系，也可在orm声明逻辑关系，EF不支持，通过Linq和拉姆达表达式组合；但是typeorm和prisma支持）,在EF或者typeorm，prisma中可以使用A.B.C 结合include方式进行懒加载方式的获取值，尤其在多对多场景，分页变得复杂，视图不可取

3、注意懒加载，并能看到SQL的执行方式。实在不行，就写SQL，子查询，也不能用视图。

4、视图存在的意义是

　　1、原始数据，这个原始数据充满了大量的冗余，冗余的特性不在于列冗余，而在于行冗余，行冗余数据的处理复杂高，面临着很多问题，比如无一列主键，出现了大量的多列主键，无主键和多列主键的笛卡尔没有意义。

一个人：多个小孩：每个小孩有几本书。1*N*N。当以这个人为主时，mygod，大量的无用行列数据出现了

　　2、视图是结论，结论性后再查询，无法进行在中间表查询条件的参数化是重要的问题，子查询的参数无法定治

 

在项目中尽量减除视图对于项目的影响。改用关系，关系描述不了的视图可以增色。好吧，我们写存储过程，吃饱撑的

存储过程处理业务，包括业务查询复杂度高的，数据处理，带业务的