打车网站开发,pinthis wordpress,网站开发项目工期流程,网络销售是做什么在做一些比较复杂的DB数据导出时#xff0c;有时会要求“将不固定的多行数据组合成一个字符串返回”。例子#xff1a;ISV Portal中就遇到了类似的情况#xff0c;要求对于每一个APP#xff0c;返回其所属的所有类目名称#xff0c;类目名称之间用[,]隔开。本文就用此例子…在做一些比较复杂的DB数据导出时有时会要求“将不固定的多行数据组合成一个字符串返回”。例子ISV Portal中就遇到了类似的情况要求对于每一个APP返回其所属的所有类目名称类目名称之间用[,]隔开。本文就用此例子来介绍。在具体陈述实现方案之前我们先介绍下我们即将操作的表结构SQL desc app_category_link;Name Type Nullable Default CommentsAPP_CATEGORY_LINK_ID VARCHAR2(20) 主关键APP_ID VARCHAR2(20) 应用IDAPP_CATEGORY_ID VARCHAR2(20) 应用类别ID其中字段APP_ID和APP_CATEGORY_ID是一对多关系对于该类型的问题总结一下大致有如下几种常见方案方案1sys_connect_by_path start with 。。。 connect by 。。。 prior 分析函数从上面的这个公式中我们可以看出该方案主要是通过分析函数和父子级联查询来完成一般是一条SQL搞定比较省事。首先来看几个具体的实现SQL。具体实现1SELECT app_id,ltrim(max(sys_connect_by_path(app_category_id, ,)), ,) categ_idsFROM (SELECT app_id,app_category_id,app_category_id || | || rn rchild,app_category_id || | || (rn - 1) rfatherFROM (SELECT app_id,app_category_id,row_number() over(PARTITION BY app_id ORDER BY app_category_id) rnFROM app_category_link))START WITH rfather LIKE %|0CONNECT BY PRIOR rchild rfatherGROUP BY app_id;具体实现2select app_id,ltrim(max(sys_connect_by_path(app_category_id, ,)), ,) categ_idsfrom (select t。app_id,t。app_category_id,min(t。app_category_id) over(partition by app_id) categ_min,(row_number() over(order by app_id, app_category_id)) (dense_rank() over(order by app_id)) numidfrom app_category_link t)start with app_category_id categ_minconnect by numid - 1 prior numidgroup by app_id;具体实现3select app_id,ltrim(max(sys_connect_by_path(app_category_id, ,)), ,) categ_idsfrom (select t。app_id,t。app_category_id,(row_number()over(partition by app_id order by app_category_id)) numidfrom app_category_link t)start with numid 1connect by numid - 1 prior numidand app_id prior app_idgroup by app_id;具体实现4select app_id,ltrim(sys_connect_by_path(app_category_id, ,), ,) categ_idsfrom (select t。app_id,t。app_category_id,(row_number()over(partition by app_id order by app_category_id)) numidfrom app_category_link t)WHERE connect_by_isleaf 1start with numid 1connect by numid - 1 prior numidand app_id prior app_id;请注意看4种实现方式的区别下面分别介绍下这4种实现方式的具体思路第1种实现采用了1个分析函数、2次子查询、一个like、以及父子级联查询字段值连接可以猜测下性能肯定不咋的2次子查询本来已经很耗时了对查询出来的结果集还要用like匹配速度就更慢了此法可以查询到我们需要的具体数据但是效率很低不可取他的实现思路是利用待查询字段值与各APP下面各类目ID的序列值进行组合并作为父子关系级联的依据第2种实现采用了3个分析函数、1次全表扫描、以及父子级联字段值连接和第1种实现比较而言的话效率会高不少他的实现思路是利用各APP对应的最小类目ID作为父子级联的开始点而父子级联的依据是row_number()dense_rank()这样做主要是为了避免无限循环第3、4两种实现思路基本上是一样的都是1个分析函数、1次全表扫描、以及父子级联字段值连接从代码长度来说比前2种实现方式简洁了不少思路也清晰了很多直接利用各APP对应类目ID的序列值作为父子级联的开始点和连接依据但仔细看看两者的SQL会发现第3这种方式用到了group by子句而第4种实现却没有用到而是在where子句中添加了connect_by_isleaf 1 的查询条件从性能上来看应该是第4种实现方式更高但他只能在10g及其以后的版本中才能使用connect_by_isleaf 字段是10g中新提供的一个伪列他可以用来判断该条记录是否是树形记录的叶节点不过还在用9i版本的可能就有些可惜了综合以上分析对4种实现方案个人推荐使用第3、4两种实现方式具体哪种可以看所用oracle的版本而定简而言之这种实现方式优雅、简洁、高效。全部
