求高手这样的SQL怎么写

NNX

原帖由 NoChoice 于 2010-11-5 11:03 发表
各位高手献身，谢谢。我想用标准的SQL语句解决这个功能（移植方便）
性能现在不太考虑，也就几万条~十几万条数据
如17#说的，如果是20C，或者2000C，好像就有问题了，有没有完美解决方案？
26#的情况应该没有，就是最后一个字母 ...

最后字母只可能一位的情况下， substring (property, 1, len(property)-1) ？

乱码

原帖由 NoChoice 于 2010-11-5 11:03 发表
各位高手献身，谢谢。我想用标准的SQL语句解决这个功能（移植方便）
性能现在不太考虑，也就几万条~十几万条数据

如17#说的，如果是20C，或者2000C，好像就有问题了，有没有完美解决方案？

26#的情况应该没有，就是最后一个字母 ...

用partition你随便加条件，用逗号分开就好，现在是partition by Name,substring(Property,1,1)
你可以改成：partition by Name,substring(Property,1,10)，substring(Property,11,50).......

前提条件是比较的那些字符段的长度是一定的

北风

完美的解决方案就是你把这个表变成，
name varchar(255), property1 int, property2 char(1)
或者#t
然后一切都好搞了
这是一个典型的，想用逻辑code解决设计缺陷的例子

北风

substring遇到长度不同的话，order by就会不对，要用int

choco2468

技术性的东西 看了头痛， 我继续去找没营养的东西看... (monkey28)

NoChoice

原帖由 北风 于 2010-11-5 11:22 发表
完美的解决方案就是你把这个表变成，
name varchar(255), property1 int, property2 char(1)
或者#t
然后一切都好搞了
这是一个典型的，想用逻辑code解决设计缺陷的例子 ...

你说得太对了，这是一个典型的，想用逻辑code解决设计缺陷的例子
Design是多么重要啊(paopaobing(11))

乱码

change schema is BIG thing.your system might crash because of this.
不要忘了还有其他的针对这个table的operation

几十万条records不像是小小不然的table.

good luck!!

澳贼

原帖由 乱码 于 2010-11-5 11:44 发表
change schema is BIG thing.your system might crash because of this.
不要忘了还有其他的针对这个table的operation

几十万条records不像是小小不然的table.

good luck!!

当然不是改，而是新建一个ｔａｂｌｅ．然后弄个程序ｆｅｅｄ

乱码

原帖由 澳贼 于 2010-11-5 12:24 发表


当然不是改，而是新建一个ｔａｂｌｅ．然后弄个程序ｆｅｅｄ

这样data integrity会有问题，dba那边基本上通不过。

这种query在我经历的projects真的是小case，比它麻烦1000倍的多了去了，所以dba作data modeling的时候，一定得加倍小心，normalization/demoralization都要有令人信服的理由，这跟经验相当有关.

澳贼

原帖由 乱码 于 2010-11-5 12:57 发表


这样data integrity会有问题，dba那边基本上通不过。

这种query在我经历的projects真的是小case，比它麻烦1000倍的多了去了，所以dba作data modeling的时候，一定得加倍小心，normalization/demoralization都要有令人信服的 ...

那就做个ＵＤＦ解决？？

北风

说实话，没有人愿意去改schema，即使真的要改，也要多方参与，往往有时候很难周全
绝大多数时候，大家还只是抱怨一下，这设计不合理啊
然后忍了。。。所以很难要求完美

尽量避免用udf，个人觉得那是performance的毒药

用temporary table吧，虽然也不是很好的方法

当然直接那样substring再加group by也能行，只是不太清晰
partition在sql 2005之后才有

月亮

从数据库角度来看，这个property完全没问题，并不需要改。不能为了取数据的时候方便而把一个数据分成两块来存储，这样取的时候是方便，但存的时候费劲了，还容易出错。而且从app调用的时候也费劲，要读两个column，然后粘一块儿

北风

我不清楚楼主的具体情况，但是看起来这property是指2个property，只是当时设计的时候放在一起了

原帖由 月亮 于 5/11/2010 13:19 发表
从数据库角度来看，这个property完全没问题，并不需要改。不能为了取数据的时候方便而把一个数据分成两块来存储，这样取的时候是方便，但存的时候费劲了，还容易出错。而且从app调用的时候也费劲，要读两个column，然后粘一块儿 ...

IsDonIsGood

原帖由 乱码 于 2010-11-5 12:57 发表


这样data integrity会有问题，dba那边基本上通不过。

这种query在我经历的projects真的是小case，比它麻烦1000倍的多了去了，所以dba作data modeling的时候，一定得加倍小心，normalization/demoralization都要有令人信服的 ...

同感，这不是掌握denormailize/noramilze原则就能做好的，根据不同的business requirements设计 变化很多，还要考虑到将来的可扩展性。没有经验真的是设计不出好的database schema
一旦db schema是bad design那开发维护的时候就惨了~~
still suffering~~

IsDonIsGood

原帖由 北风 于 2010-11-5 14:12 发表
说实话，没有人愿意去改schema，即使真的要改，也要多方参与，往往有时候很难周全
绝大多数时候，大家还只是抱怨一下，这设计不合理啊
然后忍了。。。所以很难要求完美

尽量避免用udf，个人觉得那是performance的毒药

用temporar ...

这种情况下temporary table是个不错的方法，而且数据不是多，应该不会有performance的问题

澳贼

原帖由 北风 于 2010-11-5 14:12 发表
说实话，没有人愿意去改schema，即使真的要改，也要多方参与，往往有时候很难周全
绝大多数时候，大家还只是抱怨一下，这设计不合理啊
然后忍了。。。所以很难要求完美

尽量避免用udf，个人觉得那是performance的毒药

用temporar ...

ＵＤＦ　不也是建ｔｅｍｐ　ｔａｂｌｅ，然后包装一下么？

黑山老妖

oracle PL/SQL 可以做到。
你是MS Access我就不知道了。

[ 本帖最后由 黑山老妖 于 2010-11-5 17:32 编辑 ]

黑山老妖

Oracle这么做：

select name, substr(property,1,1)||max(substr(property,2,1) as property
from table
group by name, substr(property,1,1)

大家给我加分吧。

[ 本帖最后由 黑山老妖 于 2010-11-5 17:43 编辑 ]

kr2000

原帖由 黑山老妖 于 2010-11-5 17:40 发表
Oracle这么做：

select name, substr(property,1,1)||max(substr(property,2,1) as property
from table
group by name, substr(property,1,1)

大家给我加分吧。

substr(property,1,1)||max(substr(property,2,1) as property 这句怎么解？

lxp

设计的人不懂开发，也没有遵从有繁到简的原则，没有遵守第一范式，结果是把复杂的应用引到开发去。

黑山老妖

原帖由 kr2000 于 8/11/2010 10:40 发表

substr(property,1,1)||max(substr(property,2,1) as property 这句怎么解？

substr(property,1,1) <= 取property里面的第一个字节。
max(substr(property,2,1) <= 取property里面的第二字节的最大值，因为用了group by所以可以这么做。
|| <= 是string concatenation

黑山老妖

原帖由 lxp 于 8/11/2010 10:54 发表
设计的人不懂开发，也没有遵从有繁到简的原则，没有遵守第一范式，结果是把复杂的应用引到开发去。

By the time you realise how bad someone has designed something, it's usually too late to change it. You can only work around it or try to optimise it.
Speaking from experience here...
(paopaobing(40))

rdcwayx

1. $ cat infile
   
2. Name(string) Property(string)
   
3. ----------------------------
   
4. zhang         1B
   
5. zhang         1C
   
6. li            1A
   
7. li            1B
   
8. li            1C
   
9. wang          1C
   
10. wang          1A
    
11. wang          2A
    
12. li            2C
    
13. 
    
14. $ awk '
    
15. NR>2{split($2,a,"");b[$1 FS a[1]]=(b[$1 FS a[1]]>a[2])?b[$1 FS a[1]]:a[2]}
    
16. END{for (i in b) print i b[i]}
    
17. ' infile
    
18. 
    
19. li 1C
    
20. li 2C
    
21. wang 1C
    
22. wang 2A
    
23. zhang 1C

复制代码