谁是高手，帮忙解决两个SQL语句问题吧,在线等

tangyi303

1，如何用SQL命令从一个表格中抽取凡是在闰年定的货物？
2，某公司要给所有"CLERK"的人的工资涨15%，所有“SALESMAN"的人涨20%，其余不变，结合SQL中DECODE和CASE命令计算出结果并列出表格.多谢指教了！

[ 本帖最后由 tangyi303 于 2006-4-4 00:52 编辑 ]

greenflute

抽象地问，就抽象地答好了，按Oracle数据库来，希望没记错。

1、使用trunc函数，然后判断是否是闰年
2、select ......,namecolumn,.....,salarycolumn*decode(namecolumn,'CLERK',1.15,'SALESMAN',1.2,1),....
     根据特定需求或者表达式写法，也可以用嵌套方式。可能需要uppercase，或者乘出来的结果需要格式化等等，我这里就省了:lol:

tangyi303

原帖由 greenflute 于 2006-4-3 19:45 发表
抽象地问，就抽象地答好了，按Oracle数据库来，希望没记错。

1、使用trunc函数，然后判断是否是闰年
2、select ......,namecolumn,.....,salarycolumn*decode(namecolumn,'CLERK',1.15,'SALESMAN',1.2,1),... ...

万分感谢，但是关于用trunc函数提取闰年值得用法还是不太清楚，我给出个例子吧，请帮忙指点指点。$汗水$$汗水$
那些职员是在闰年被雇佣的。
解：select *from emp
..................?

greenflute

可以有几种方法来做，麻烦程度不同
1、to_char得到年数，再to_number进行判断，主要是百年的时候必须能被400整除，可以用mod或remainder函数。刚看了wikipedia上居然说能被3200整除的也不是闰年，晕倒$frage$，现在就开始考虑Y10K问题了？！咱们是见不到那一天啦;)。这个是判断表达式比较复杂。

2、用trunc截取日期到年，也就是该日期所在年的第一天，用add_months加到2月，再用last_day得到该月最后一天，只要该天数大于28就是闰年。这个是日期操作，但判断不多，就一个。

3、建个表，把所有已知和可见的将来（对付应用中会出现将来的日期的情况）的闰年都放进去。至于是放数字还是字符，还是年头的date数据，看情况了，应该是date数据最简单，判断时只要一个trunc即可。

4、使用上述机制之一作一个自定义函数，或者用c写本地函数，或者用java写oracle内部函数。这已经超出这个sql语句的问题了。

5、涉及到子查询，先做一个子查询，统计所有行中不唯一的年数，再套一个查询以上述方式筛选出闰年。再在主查询中使用trunc函数和in关键字来判断。这样做由于oracle的优化，子查询只执行一次，而in的判断效率又相当高，而且这种情况下该子查询结果集应当也很小，date类型效率也很高，又免去了无谓的数据类型转换，查询执行成本应该是比较小的，如果原来日期字段上又有索引，效率可能会更好一些。

6、如果日期字段有索引，取max和min年数。然后把这段时间中间的闰年算出来，再在查询里用上述方式判断。这个的难点在于动态创建可扩展数组，比较麻烦。但是io比较少，只有原表的选出列和日期的索引上的最多两个io。

7、把3和5结合起来，做一个闰年的视图。然后进行select，连临时sql解析都省了。至于是否用物化视图，看具体情况了。这样的查询任务，应该用不着，呵呵。

暂时就想起来这么多了，好久不干活，已经很生疏了>_<

给一个参考链接：http://www.techonthenet.com/oracle/index.php
当然最权威的还是oracle的文档，docs.oracle.com，如果你第一次访问，送你一个经典表情:o，呵呵。

[ 本帖最后由 greenflute 于 2006-4-4 14:19 编辑 ]

greenflute

没有表结构和具体要求，也只能这样泛泛地写了。不过还是建议你把函数参考仔细看一下，并不难的。:)

小牛军队

最有效率的方法应该是在录入时判断是否为闰年，然后新增一布尔值的列来表示闰年，这样读取和查询的速度都有保证，否则每次读取都进行计算是很费资源的。。。。。。对于已存在的数据最好来一次update，一劳永逸。。。。

至于如何判断闰年，这个不用到这里来问吧。。。。。。

greenflute

首先，本贴楼主的问题是SQL问题，而且clerk表，emp表，salesman字段，记得就是Oracle sample schema的东西，自然解决问题的立足点是PL/SQL，我第二个回复确实有点儿多余，有灌水嫌疑，呵呵;)

第二，就应用开发过程中修改现有表的结构而言，应该说是比较不提倡的，新增对象尚可，断然修改现有表结构是很危险的，有时候也是不允许或不可能的。还以该schema为例，手边没oracle，不过该schema还是有一部分基于clerk表的视图和查询的。如果草率修改该表结构，现有应用必然受到一定的影响，尤其是未明确指出列名的查询。姑且不说闰年的货物这样的要求明显只是练习中才可能出现的要求，即便真是实际应用，新增列会引发新的潜在问题。
      A，对其他应用的影响，表结构修改，所有引用该表的package，view，proc，func，form都会失效，需要重新编译解析，进而相关的更多的plsql对象受影响，包括客户端，虽然再编译是自动的，也会造成相应的系统资源消耗，在实际应用系统中还会造成不必要的锁和等待，所以是不提倡的。以前就经历过一次，软件工程师调试软件逻辑问题，在生产系统上重编译一个重要的package，导致应用挂起，数十个客户端无法正常工作，直到数据库工程师赶到才得以解决，由于是关键应用，后果比较严重，险些危及一些人的乌纱帽。至于现有应用的调整，大系统下就更无法估计了。
      B，对存储的影响，要对该表加独占锁，进而涉及到segment，tablespace这一级别的全局锁，这方面系统资源的消耗和对性能的影响就不是几个date数据的操作所能比得了的，数据量愈大，代价愈高，虽然使用查询方式计算量也随之增加，相对还是比较有效率的。而且对于大型应用，可能涉及到分区表，以及裸设备存储，相关存储方面的调整，可比写查询要麻烦和危险多了。
      C，数据本身效率问题，oracle的date就是按整数存的，因此效率上是不存在劣势的，boolean在oracle里也使用的整数。这也符合这么一个逻辑，记录的存储方式的简洁程度和系统的高效率是正相关的。当然了oracle从tablespace到segment，extend，再到block的结构是很复杂的，但是打开一个datafile，看看里面的记录数据，你就会发现其中有趣的现象了。
      D，数据冗余问题，已经包含在现有字段中的信息，是不太有必要重复存储的。而且鉴于闰年本身的性质，还引出了索引问题。
      E，对于比较稀疏的数据列做不做索引要根据应用的情况来决定的，对于闰年这样的，如果作索引，b树索引没什么效率，bitmap索引只是比较适用于写操作较少的表。另外索引本身还占用相当部分的存储空间，而如果不索引，那么按oracle的CBO策略，还不如让它少读几个数据块来得划算。

有些东西记不清了，不对的地方欢迎批评指正:lol:

其实倒也没有其他意思，只是想说，应该注意什么时候应该朝哪个方向考虑，慎用一些看似方便快捷，实则含有众多隐患的方法。当然本例就无所谓了，呵呵:P