不知道各位对稍微海量点的数据怎么操作

深圳情缘

有一功能，需要查询部门下的所有子部门树；
然后根据所有的部门获得该部门下的所有员工；
最后对这些员工进行遍历，执行 .........where userName='员工名字' 的查询；
最后，把查询的结果show出来。

由于有可能某个人身兼两职  譬如说既是某部门员工，又是令一部门的员工，所以我使用Set来存放员工
查询用级联的时候，当传入的是根部门，大概要花40分钟；
查询用SQL的时候，当传入的是根部门，大概要花1分钟；

ps:我开发用的机器不咋的，
员工人数大概2W。

lyhiving

不懂mssql咋搞

用mysql的话在几秒钟可以搞定，设定缓存后效率更高

深圳情缘

如果只是把用户集合查出来的话，其实只需要十几秒（我的机器是2000的经典配置，机器比较差），所以可能花的时间跟楼上的差不多吧；
不过需要根据用户集合，遍历用户集合，对每个用户都再执行两次数据库查询，也就是要执行多四W次查询，所以居然要花上1分钟左右；

深圳情缘

根据用户集合，遍历用户集合，然后对HQL语句添加OR条件，而不是每次遍历执行一次语句；
遍历完后才对HQL语句执行操作。

wool王

有点看不太明白楼主的需求.

按我们这边的做法,是放弃Hibernate关联,直接用SQL(可以写多表查询语句).对于出来的结果再组装并放到数据结构中(楼主貌似是放到HashSet中).对于查询条件,设置为索引(比如楼主的userName).

这样做的效率具体如何我没多大概念,不过基本上对于那些百万级别数据的查询,响应时间都不会超过1分钟.用的是oracle.

期待更多观点...

hansen

同意LS的做法，我经常做的查询都是5百万以上数据级别的，有些机构也是树形结构，对查询条件加上索引，也不用1分钟。
我用的是Oracle

sasadong

很简单。
如果你可以设计数据结构（就是说由你来设计数据结构），我可以提供一个设计，1秒都不用，结果就出来了。

首先，是组织结构树，肯定是如此设计
ORG_ID,  ORG_NAME, PARENT_ID
这是最简单且必须的结构，  在此基础上，增加一个字段，PATH，用于保存部门之间的级别关系，类似我们的目录全路径。

例如
1，根部门，0，/ROOT
2，人事部，1，/ROOT/HR
3，技术部，1，/ROOT/TECH
4，研发1组，3，/ROOT/TECH/DEV1
5，研发2组，3，/ROOT/TECH/DEV2

sasadong

然后剩下的就是，建一个用户USER到ORG的关联表

USER_ORG(  USER_ID,  ORG_ID  )


像楼主的需求，大概可以这么实现

SELECT xxx   FROM USER_ORG,USER,ORG   WHERE   USER_ORG.USER_ID=USER.USER_ID AND USER_ORG.ORG_ID = ORG.ORG_ID AND USER.NAME=姓名  AND ORG.PATH LIKE 你所要查询的根部门的路径，例如查询技术部，是   '/ROOT/TECH%'


优化一下语句，我不太会mssql的优化所以没做了，降低第一次筛选所或得ORG的行数来做关联（部门的数目不会超过1000个吧？所以全文本匹配的耗时不会长），剩下的都是可以通过索引达到性能的提升。

[ 本帖最后由 sasadong 于 2006-12-2 22:48 编辑 ]

wool王

LS的方法在编辑的时候是不是会比较麻烦呢?修改一个部门(组)的位置,得改动两个地方.得保证parent_id和path的内容同步吧?

不知LS有什么好的方法解决这个问题?

sasadong

PATH的值是我们设计的，如果你想让这个字段有意义，那么可以为每一个部门设定一个“编码”，如ROOT，TECH
如果嫌麻烦，这个编码干脆用“标识”代替。标识是指记录的主键，一般是一个自增的ID

然后每一次INSERT或者UPDATE之后（是在成功之后执行，否则在INSERT时是不知道自增数字型主键的值的），执行

UPDATE ORG
   SET PATH=CONCAT(
        IFNULL(
              (SELECT PATH FROM ORG WHERE ORG_ID=当前编辑记录的PARENT_ID),
              ''
        ),   
        '/',
        当前编辑记录的ORG_ID
   )
  WHERE ORG_ID = 当前编辑记录的ORG_ID

CONCAT是字符串连接操作函数。

这样就会形成
/0
/0/1
/0/2
/0/1/3
/0/1/4
这样的PATH了

这样的结构非常适合避免“树型”结构中、对某一节点的子节点进行遍历并执行操作的需求。

但是回看lz的需求，好像是基于内存操作的，这个部门树（tree结构）假如是在内存中，用户与部门的关联关系（一个set结构）也在内存中。那么就完全没必要用sql了，可以使用算法遍历得到一个部门数组，然后以此再筛选出符合姓名条件的用户数组（set结构必须保存有姓名数据，否则无法执行）。
最后在执行对用户的操作时（例如使用二维表格列出这些用户的信息，不明白是不是这样的意思），才使用sql查询，利用IN语句（IN语句最好是IN记录的主键，例如USER_ID，这样才能最大限度利用索引。如果使用的是USER_NAME，在USER_NAME上做索引的话也能达到较高效率，但是字符串匹配速度比数值匹配慢好几倍） ，不知道多爽。
SELECT * FROM USER WHERE USER_ID IN (  目标用户id   )

[ 本帖最后由 sasadong 于 2006-12-4 00:07 编辑 ]

wool王

楼上的技巧,收集.受用.

小康

不考虑网络速度的情况下
把所有的记录读取出来，建立一个多叉树。这棵树就是答案。
效率 lgN*a  假设每棵树的大小为x字节， x<a<10x。
2W个数据，不用10MS应该可以搞定。

wool王

我觉得楼上师弟太理论化了.有时不可能将所有持久化数据都放到内存中的.更何况,将持久化数据转换成数据结构本来就会很影响效率.期待更多讨论.

thiswwww

用SET只是用来存放唯一的数据吧，楼主不干脆做个视图，然后下条件查询？你只要是明细数据而已，最明细就是员工名称跟部门，或者直接group by 员工名称，部门

小康

我觉得楼上师弟太理论化了.有时不可能将所有持久化数据都放到内存中的.更何况,将持久化数据转换成数据结构本来就会很影响效率.期待更多讨论
典型的做数据库的回答

不过不懂
什么是持久化数据 ？？？？？
无论什么数据，从字符串转化为相应的数据，这个时间应该可以忽略不计。1G的字符串转化为数字，估计也就是几秒钟。有1G这么大吗？

另外，不一定要把数据放到内存中才可以排序
还有，如果要排序上几十秒，那这个时间可远远大于获得数据的时间。
遇到过，我们广工一个师兄，在某个公司做CTO，做得一个主从表查询，说用了小型机需要一分多钟，靠，写个程序处理做成COM，几秒钟普通PC机就可以运算完

小康

提一个项目，时间旧了，不是很清楚。

有个股票项目，服务器每三秒会接收所有的股票的数据。好像是3K-10K条记录。大概这个数量级。
然后，有大概1K个用户，需要每三秒，从这个服务器获得数据1－30条记录，要实时显示相关信息。
当时两方意见
一方，数据库效率不够高，不可以使用数据库实现
二房，目前的 数据库效率已经够高的了，其他用户直接从服务器的数据库从获取数据就好。

iptton

LS  下文？

不是很懂，感觉楼主讨论的是在一定的软件环境限定下做的
个人认为数据库为了通用性，不可避免有性能方面的牺牲

小康

数据库的性能，肯定是低很多了。
但是在开发效率方面，应该是提高很多。但是，应该不是什么都行都用数据库来做才是。