[20190930]关于数据结构设计问题.txt

[20190930]关于数据结构设计问题.txt --//快放假，没有什么事情，我整理电子邮箱，发现N年前乙方一封电子邮件，现在读起来真的苦笑不得。 --//想起以前刚开始学习oracle时，一位开发给我写的一段话，不知者无畏，现在看来这句号应该送还给对方。 1.出于安全考虑我不贴出具体内容，我大概描述我提的建议： --//一个表有一个字段result，里面记录一些从仪器上读取的记录。格式如下： 201310230915:111,222,333,444....,888 --//很明显冒号前面是一个时间，仅仅没有秒罢了。实际上严格讲这个设计违反数据结构设计的。因为把2个属性的内容放入一个字段。 --//其实我并不关心这些，我仅仅做优化工作，因为经常执行这样类似的查询条件： select * from x where patient_id='123' and result like '201310230915%'; --//语句很简单，通过patient_id='123'条件返回记录很多，导致逻辑读有点高。我不大可能建立复合索引，因为result字段占用空间很 --//大。我仅仅提出建议这样设计不合理,如果分开2个字段更好，这样查询语句可以写成如下： select * from x where patient_id='123' and result_time = to_date('201310230915','yyyymmddhh24mi'）; --//实际上可能对方理解我要求改数据结构,我个人从来不会提那些"不现实"的改动，我仅仅要求把这条语句改写如下： select * from x where patient_id='123' and substr(result,1,12) = '201310230915'; --//看看对方的回复： --//大概意思是这样设计可以节省存储空间，按照他的理解字符串保存的'201310230915'(少了秒)比采用日期格式保存的时间更节省空间。 --//真的是"不知者无畏",很明显对方并不知道和了解oracle日期存储格式以及占用空间大小。oracle的日期存储仅仅占用7个字符。 --//而那一串表示时间的字符串占用12个字符，而且取日期不要秒很简单，仅仅使用trunc函数就可以实现。 SCOTT@test01p> select sysdate,trunc(sysdate,'mi') ,dump(sysdate,16) c40, dump(hiredate,16) c40,hiredate from emp where rownum=1; SYSDATE             TRUNC(SYSDATE,'MI') C40                                C40                            HIREDATE ------------------- ------------------- ---------------------------------- ------------------------------ ------------------- 2019-09-30 20:31:50 2019-09-30 20:31:00 Typ=13 Len=8: e3,7,9,1e,14,1f,32,0 Typ=12 Len=7: 77,b4,c,11,1,1,1 1980-12-17 00:00:00 SCOTT@test01p> select sysdate,dump(sysdate,16) c40, dump(hiredate,16) c40,hiredate from emp where rownum=1; SYSDATE             C40                                      C40                                      HIREDATE ------------------- ---------------------------------------- ---------------------------------------- ------------------- 2019-09-30 20:32:49 Typ=13 Len=8: e3,7,9,1e,14,20,31,0       Typ=12 Len=7: 77,b4,c,11,1,1,1           1980-12-17 00:00:00 --//注:直接取sysdate的类型与保存在数据库的日期类型有一点点不同. --//我依稀记得去年我还看了这个应用项目,语句还是使用前面的like。我一直有一种感觉，开发很不愿意改动"执行"正确的代码，实际 --//上执行错误的代码也不会改动，而对于使用具体用户提的建议却非常认真及时对待(至少比对我们要好一些)，实际上具体用户一些建 --//议在我看来完全没有必要实现，可能看问题的角度真的不同^_^。 --//包括内部一些开发项目也是一样，我看一下N年前我提的建议到现在都没有改，甚至执行错误的语句。 2.再来看看另外的项目： --//我们生产系统,表中存在大量表示状态的字段status,flag字段，开发全部使用number类型，实际上又是开发不了解oracle number类 --//型的存储仅仅0占用1个字节。其他数字至少占用2个字节。 --//而且该字段经常改动,往往是0修改其他值，这样就不能实现就地修改，要改写行目录的偏移量，而且这些字段可能还会出现在各种 --//索引中的一部分。还有一些开发使用-1表示某些状态，很明显不了解-1在oracle存储占用3个字节。我曾经开玩笑讲使用-1,不如使用 --//100,1000,1000呢？ SCOTT@test01p> select dump(-1,16),dump(1000,16) from dual; DUMP(-1,16)           DUMP(1000,16) --------------------- ----------------- Typ=2 Len=3: 3e,64,66 Typ=2 Len=2: c2,b --//继续看看链接,不再贴出： [20180309]不好的数据结构设计.txt =>http://blog.itpub.net/267265/viewspace-2151657/ [20180312]不好的数据结构设计2.txt=>http://blog.itpub.net/267265/viewspace-2151736/ --//真心无法体会这样设计带来的好处!! 3.继续： --//再谈自己遇到的一个ms sqlserver数据库，N前遇到的问题，同事要求协助解决问题。 --//当我连接数据库才发现开发定义数据字段那个乱啊,简单讲比如patiend_id字段：有一些定义类型是nvarchar2.一些表定义 --//为varchar2，其他字段就不在提了，一个表里面一部分用nvarchar2，另外一部分使用varchar2,简直乱的一塌糊涂。 --//我当时想这样的项目怎么能在许多医院上运行，没有良好的硬件根本撑不住。 --//我当时只能找来实施人员讲明具体的情况，不过讲完我就不在理会这些问题，顺便说一下我个人并不主张nvarchar2类型，其实目前 --//仅仅姓名字段使用narchar2有点意义。不过过了几天，对方跟我讲他花了一个晚上时间，修改很大部分字段比如patient_id全部统一 --//使用nvarchar2,还跟我讲感觉现在系统快了许多... 4.总结： --//不小心有写了一大堆。我在这个行业见到许多奇葩事情，有时候真心很无奈..........