SELECT, hierarchical queries and JOIN

Question

Hi everyone,
I have a small SELECT statement but I can't find an easy solution.
Look at this situation:
drop table departments;
CREATE TABLE departments
  dpt_id NUMBER(10) UNIQUE,
  dpt_name VARCHAR2(100),
  dpt_parent_id NUMBER(10)
TRUNCATE table departments;
INSERT INTO departments VALUES(1, 'Company', null);
INSERT INTO departments VALUES(2, 'HR', 1);
INSERT INTO departments VALUES(3, 'SALES', 1);
INSERT INTO departments VALUES(4, 'IT', 1);
INSERT INTO departments VALUES(222, 'Helpdesk', 4);
INSERT INTO departments VALUES(223, 'French Speaking', 222);
INSERT INTO departments VALUES(224, 'Another level', 223);
INSERT INTO departments VALUES(5, 'LEGAL', 1);
INSERT INTO departments VALUES(66, 'Recruitment', 2);
INSERT INTO departments VALUES(33, 'Logistics', 2);
INSERT INTO departments VALUES(39, 'Fleet management', 33);
INSERT INTO departments VALUES(31, 'Local Sales', 3);
INSERT INTO departments VALUES(60, 'European Sales', 3);
INSERT INTO departments VALUES(61, 'Germany', 60);
INSERT INTO departments VALUES(62, 'France', 60);
INSERT INTO departments VALUES(620, 'Paris', 62);
INSERT INTO departments VALUES(621, 'Marseilles', 62);
INSERT INTO departments VALUES(38, 'American Sales', 3);
INSERT INTO departments VALUES(34, 'Asian Sales', 3);
CREATE table persons
  person_id NUMBER(10) UNIQUE,
  person_name VARCHAR2(100),
  person_dpt_id NUMBER(10)
truncate table persons;
INSERT INTO persons VALUES(1, 'Jim', 2);
INSERT INTO persons VALUES(2, 'Jack', 621);
INSERT INTO persons VALUES(3, 'John', 620);
INSERT INTO persons VALUES(4, 'John', 224);
INSERT INTO persons VALUES(5, 'Fred', 61);It's a simple hierachy like the one we can find in HR schema. The link between an department and its parent is with parent id. THe following statement build the whole tree:
SELECT dpt_id, level, LPAD(' ', LEVEL-1)|| dpt_name
  FROM departments
START WITH dpt_parent_id IS NULL
CONNECT BY dpt_parent_id = PRIOR dpt_id;As you can see in the script above, I have a few people assigned to these departments. It's also a classic situtation...
I would like to have something like this:
WITH temp AS
  SELECT dpt_id, dpt_name, SYS_CONNECT_BY_PATH(dpt_name, '#') as full_path
    FROM departments
   START WITH dpt_parent_id IS NULL
CONNECT BY dpt_parent_id = PRIOR dpt_id
SELECT p.person_name, d.dpt_name, --d.full_path,
       regexp_substr(d.full_path, '[^#]+', 1, 2, 'i') as t1,
       regexp_substr(d.full_path, '[^#]+', 1, 3, 'i') as t2,
       regexp_substr(d.full_path, '[^#]+', 1, 4, 'i') as t3,
       regexp_substr(d.full_path, '[^#]+', 1, 5, 'i') as t4
  FROM persons p
  JOIN temp d ON d.dpt_id = p.person_dpt_id;This is the exact output I want, but I wonder... Is it possible to do it without the factored sub-query? It's nice and works fine but I had to precompute the whole path to split it again. I mean, this should be possible in one step. Any suggestion?
I'm using Oracle 10g
Thanks,

Answer 1

Hi,
user13117585 wrote:
... But sometimes, I just find the statements difficult for what they do. For example, my previous one. I have a person, and I want to see his department and the path in the tree.Actually, you want more than that; you want to parse the path, and display each #-delimited part in a separate column. If you didn't want that, then you could do away with the 4 REGEXP_SUBSTR calls, like this:
WITH temp AS
  SELECT dpt_id, dpt_name
  ,       SUBSTR ( REPLACE ( SYS_CONNECT_BY_PATH ( RPAD (dpt_name, 15)     -- Using 15 just for demo
           , 16
           )     as full_path
    FROM departments
   START WITH dpt_parent_id IS NULL
CONNECT BY dpt_parent_id = PRIOR dpt_id
SELECT p.person_name, d.dpt_name, d.full_path
  FROM persons p
  JOIN temp d ON d.dpt_id = p.person_dpt_id;Output:
PERSON_N DPT_NAME      FULL_PATH
Jim      HR            HR
Fred     Germany       SALES          European Sales Germany
John     Paris         SALES          European Sales France         Paris
Jack     Marseilles    SALES          European Sales France         Marseilles
John     Another level IT             Helpdesk       French SpeakingAnother levelAs you can see, full_path is one giant column, but it's formatted to look like 4 separate columns, forresponding to your original t1, t2, t3 and t4. I limited the output to 15 characters, just for debugging and posting purposes. You can use any number of characters you like.
It's too complex for this simple thing.It would be nice if there was something simpler that did exactly what you wanted, but I'm not sure it's reasonable to expect it in every case. I asked a lot of questions in my first message, but I'm not sure you've tried to answer any of them, so I'm not sure why you're unhappy with the query you posted. I can think of lots of ways to change the query, but I have no way of telling if you would like them any better than what you already have.
And hopefully, I know where to start in the hierarchy and I know where to stop. If I had to show all the levels and have one column by level dynamically, I'd be stuck. Sorry, I don't understand this part.
Are you saying that it seems inefficient to generate the entire tree, when perhaps few of the nodes will have have matches in the persons table? If so, you can invert the whole query. Instead of doing the CONNECT BY first and then joining, do the join first and then the CONNECT BY. Instead of doing a top-down CONNECT BY, where you start with the parentless nodes (whether or not you'll ultimately need them) and then find their descendants, do a bottom-up CONNECT BY, where you start with the nodes you know you'll need, and then find their ancestors.
I just find it difficult for such a simple need. Again, there are lots of things that could be done. If you won't say what you want, that makes it hard for me to tell you how to get it. All that I've picked up for sure is that you don't like doing a sub-query. That's unfortunate, because sub-queries are so basic. They have very important been since Oracle 8.1, and they don't seem to be going away. Quite the opposite, in fact. You need sub-queries for all kinds of things, not just CONNECT BY. To give just a couple of examples, they're the only thing that make analytic functions really useful, and they simplfy chasm traps (basically, multiple 1-to-many relationships on the same table) considerably. I'm sorry if you don't lke sub-queries, but I don't see how you can work in this field and not use them.
Edited by: Frank Kulash on Nov 15, 2011 3:18 PM
Revised query