I am kind of newbie in Oracle. Got stuck in the below: I have the below 2 tables:
Site:
**SiteID|SiteName**
1 Sydney
2 Newyork
3 Delhi
People:
**RecordID|PeopleID|SiteID**
1 1 1
2 1 2
3 2 2
4 3 1
5 3 2
6 3 3
Now in my query I want an output something like this:
**PeopleID | AssignedSites**
1 Sydney,NewYork
2 Newyork
3 Sydney,NewYork,Delhi
- Few more points:
-The solution should work in Oracle 10g as well as 11g also.
-I have given small subset of data in the above example for brevity.But, in my prod scenario, one Person can be associated with 1000+ locations and there could 1000+ such person, so the solution should not break in that case!
Any help will be highly appreciated.
Thanks in advance.
I think I am close to it, just need a small help: I have created a function GetSiteName, which returns the site name against the SiteID. Now I am using the below xmlagg where in I need to call this function GetSiteName:
Basically need help in calling the function from inside xmlagg, any thoughts?
Try using
XMLAGG
like this:If you need the concatenation in a particular order, say increasing order of SiteId, then add an
order by
clause in the xmlagg:EDIT:
If you want display result for all those people which are assigned to site 100:
I just needed an alternative for listagg on oracle 10g and found one in this page https://oracle-base.com/articles/misc/string-aggregation-techniques.
just use wm_concat, albeit it is not supported by oracle and has been droped in 12c.
with the example above:
This is too long for a comment.
listagg()
is the obvious choice, but it is not available in Oracle 10. However, even in Oracle 11,listagg()
is limited to strings of length 4,000, and you explicitly say "Person can be associated with 1000+ locations".There are ways around this, using CLOBs, XML, and no doubt other solutions as well. However, what use is a list of locations thousands and thousands of characters long? With so many locations, you are not going to be able to put the result in a standard
varchar2()
field.Perhaps summarizing them in the database this way is not the best solution to your actual problem.