中国有着大概99%的软件公司使用SQL进行着日常的数据存取、使用请求返回进行着日常的数据展示、使用类进行着日常的数据抽象。
新架构关于数据存取问题
1、现状问题
数据处理有关的现实问题：
1）软件对数据表索引数量需要和软件对数据表数据增删改效率需要的矛盾（物理限制层面）
2）软件对数据表字段数量需要和数据表字段数量限制的矛盾（物理限制层面）
3）开发人员对索引字段顺序统一标准理解性需要和人类对事物顺序理解有限性的矛盾（标准理解层面）
4）软件对数据表数量复杂性需要和开发人员对数据表表名可读性需要的矛盾（理解层面）
5）软件对索引完整性需要和索引完整性不确定的矛盾（验证层面）
6）软件对查询多样性需要和大量数据情况下的物理限制的矛盾（物理限制层面）
7）软件对自定义字段功能需要和软件对可维护性需要的矛盾（技术限制层面）
2.1、软件对数据表索引数量需要和软件对数据表数据增删改效率需要的矛盾
软件对数据表索引数量需要，指用户往往希望软件能帮助他筛选或处理出各种想要的数据，那就需要增加大量的索引以支持软件查询或处理的速度上的用户体验需要。
软件对数据表数据增删改效率需要，指索引过多的情况下，系统的业务逻辑执行会变得越来越缓慢，用户使用量越大，对软件使用上的用户体验速度降低越明显。
例如在企业管理软件中，会需要一个“自定义高级查询”功能，需要对表的任意字段进行查询，或对表的任意多个字段进行组合查询。
假如只是对任意单个字段进行查询，也就是表需要建立与表字段一样数量的索引，来对应每一个字段的查询。
假如是对任意两个字段进行查询，也就是表需要建立大约字段数量的2次方的索引数，这已经有点不太现实了。
我们知道，一个表的字段越多，即数据插入、删除、修改也就越慢。
客户对功能需要和客户对物理限制不知情理是一个矛盾关系。
数据使用量越大，问题矛盾越渐明显。
解决办法思路：
1）在数据量很大并自定义查询的情况下，自动为当前查询的用户复制一个表并建立好索引，并提前提示用户需要建立查询表数据要等待一些时间，即要同时保障用户体验，解决客户的不知情理的问题。
2）建议简化数据连接复杂性，即让功能所涉及的表进行独立分开不进行表连接的逻辑，只有简化后才好进行复制表数据操作，否则涉及表连接太多不利于自动复制。
2.2、软件对数据表字段数量需要和数据表字段数量限制的矛盾
例如有一个咨询医生的软件，用户的角色就会有咨询的普通用户、医生用户、管理员。普通用户会有年龄、性别等信息，医生用户会有执业年龄、分科等信息。
那么普通用户信息和医生用户信息是否放在同一个表，如果放在同一个表，字段数量就会越来越多，随着软件发展未来的角色可能会越来越多，用户的字段信息只会递增。
解决办法思路：
1）普通用户信息和医生用户信息应该放在同一个概念表，但是不同的物理表，这就需要建立数据概念层。同理企业软件中员工表和用户表应该属于同一个概念表，因为员工表与用户表是一对一关系，所有一对一关系应该属于同一个概念表。
2.3、开发人员对索引字段顺序统一标准理解性需要和人类对事物顺序理解有限性的矛盾
开发人员对索引字段顺序统一标准理解性需要，指当一个表建索引时，需要选择该表的多个字段为索引字段，建立索引字段的顺序是否有统一标准的办法，如果不建立统一标准是否对系统导致不良的影响。
人类对事物顺序理解有限性，指人类对事物大小顺序的判断是很有限的，比如区分“省”和“市”优先很容易判断一致，区分“年龄”和”性别“的优先级就会出现不同的判断。
人类对于具备物理空间相关联的词会在潜意识进行了大小排序了，所以在沟通这些词时人类会很容易达成协调一致，对于与物理空间关系不大的属性，每个人的顺序感觉不一样甚至是随机性，这体现在资料、代码等协调性的降低。
大多数据库会自动匹配查询参数与索引字段进行匹配，即使查询参数顺序与索引字段顺序不一致，也会自动匹配上，开发人员需要查阅所有索引可以到数据表上查看。
是否会导致人员协调成本加大，或导致系统不稳定不高，仍有待观察和研究，但建议建立统一标准的索引字段顺序，应该是好处会更多。
2.4、软件对数据表数量复杂性需要和开发人员对数据表表名可读性需要的矛盾
软件对数据表数量复杂性需要，指软件的功能需要，往往需要建立几十个表甚至数百个表，特别在企业管理软件中特别明显。
开发人员对数据表表名可读性需要，指新开发人员对于几十个表或数百个表的理解掌握的时间要远远超过预期，或老开发人员对于大量的表的日常维护的挑战越来越大，维护迭代功能的时间也常常超过预期时间。
解决办法思路：
1）简化数据连接复杂性，即让功能所涉及的表进行独立分开不进行表连接的逻辑
2）所有一对一关系表合并成一个概念表，比如用户表与员工表，合并为用户概念表。
3）子集关系表合并成一个概念表，比如有一个表存放每个部门里绩效最高的用户信息，该表数据属于用户表的子集表。
4）统计关系表合并成一个概念表，比如有一个负责统计用户绩效平均数和总计数的存放表，该表数据属于用户表的统计表。
5）一些特殊附加表也应当合并成一个概念表，比如有一个负责检测用户某个字段是否为空，需要用一个表存放检测进度的表，该表即为用户表的特殊附加表，此时字段名的命名应该是lastCheck，表示用户表的是否最新检测字段。
6）除统计关系表以外，概念表的每一个字段的意思始终是围绕用户记录作为对象，字段作为对象的属性含义。
2.5、软件对索引完整性需要和索引完整性不确定的矛盾
软件对索引完整性需要，指软件代码逻辑涉及的所有查询或表连接处，都应当完整不漏的建立索引。
索引完整性不确定，指假如有一个索引漏掉了，在数据量少的时候并未察觉，随着数据量增加，漏掉的索引会让软件的速度体验慢慢变差的过程。
解决办法思路：
1）监视每一个表的读写速度情况并记录异常。
2）读写速度有严重情况，自动建立索引，并记录日志。
3）记录所有数据查询日志，通过分析查询日志的索引条件，与数据库的索引进行检测是否存在。
2.6、软件对多样性查询需要和大量数据情况下的物理限制的矛盾
查询日考勤表的人事部和财务部的考勤数据并按年龄进行排列：
SELECT * FROM dayTable WHERE partName = '人事部' OR partName = '财务部' ORDER BY age ASC
这是一条很常见的或过滤排序的SQL查询语句，但在数据量很大的时候，就会出现查询缓慢的清况，这个情况跟百度的查询多个关键字并按权重排序显示有些相似。这里可以理解为“查询人事部按年龄排序的数据集合”与“查询财务部按年龄排序的数据集合”的两个集合的按年龄排序并集，在有索引的情况下单独查询两个集合会很简单，再把两个集合再组合起来排序，如果数据量很大展示很多页后的数据，就会有问题，因此一般这个情况的业务场景的解决办法可能会让它不显示太后面的数据，只并集前面的几千条数据体验速度不会受太大影响。
如果软件存在大量的多样性查询语句构成，软件能支持的用户使用量就会有限，也很难往更大使用量的saas平台迈进。
2.7、软件对自定义字段功能需要和软件对可维护性需要的矛盾
在企业管理软件实施过程中，某一个表的字段是固定的，但每一个客户又需要各种额外的信息记录，就衍生出自定义自段功能的需要。
使用SQL拼接字符串，是可以实现动态字段。
引用实体以及lambda表达式来代替SQL字符串拼接，提高表的重构性（可以很容易修改名称），提高数据处理逻辑的可维护性（不容易写错SQL的单词或字母符号），缺点是不能实现动态字段，往往会采用预留几十个空白字段来实现动态字段，预留的空白字段的数据类型必需要固定数据类型。
解决办法思路：
1）使用SQL拼接字符串，应用类似C#的nameof来补充拼接字符串的可维护性的不足。
2）放弃使用SQL数据库，采用NoSql，应用类似C#的nameof来补充拼接字符串的可维护性的不足，此方法的可维护性会比使用SQL拼接字符串的可维护性更高，并且数据类型。
