,性能不佳并非关系模型之过。不可把性能和关系模型搅和在一起,不能用物理设计来指导逻辑设计,不要在逻辑设计中掺杂物理设计。逻辑设计与RDBMS无关,不能拿RDBMS来衡量本标准。一些文章中关于性能与结构关系的论述均是物理设计阶段的结论。物理设计是针对特定的DBMS的。一般情况下,表中行多则查询慢,表中行少则查询快。也可以做一个RDBMS,把用在行上的技术与用在列上的技术对调,用之则会得出相反的结论。物理的表结构有一定程度的任意性,不宜作为行业标准。表结构3.0的12×31阵可以理解为一种物理结构,它没有考虑到,矩阵的转置查询既不方便,而且速度很慢。DBMS提供了性能优化工具。可作存储优化,查询优化,未来的DBMS可能实现透明的预先连接。这些都是不牺牲范式等级和结构提升性能的途径。DBMS提供了数据分布工具,通过数据的合理分布,也能改善性能。牺牲范式等级和结构提升性能是挖肉补疮或因陋就简的做法,本标准数据库对性能的要求不高,逆规范化得不偿失。不作物理设计自然也就不考虑性能,2000问题就是节约两个字节造成的。表结构3.0的ORACLE物理设计很充分,既节省存储空间,又提高查询速度,没有使用时间换空间或空间换时间策略,其物理设计是很高明的,却得出了不合理的逻辑设计结论。所以,不必作物理设计,直接将本标准表结构当成物理的表结构即可。五、表结构3.0的设计思路猜测1.根据年鉴表,忽略特例,用关系模型设计基表2.表结构3.0ORACLE物理设计表示日值的四种结构:31×1212×311×366366×1结论:12×31更快3.物理设计结论被逻辑的表结构广泛采用。即以物理设计反过来指导逻辑设计。第二章存储内容1.采纳了所有增加数据的建议;2.存储体定义完整,状态、参数、公式均有存储体;3.资料审查依据齐全。1地表水整编数据2泥沙整编成果3工程推流数据4水文调查资料5区站拓扑存储内容构成图
全文预览
