From: | Igor Neyman <ineyman(at)perceptron(dot)com> |
---|---|
To: | Don Parris <parrisdc(at)gmail(dot)com>, Misa Simic <misa(dot)simic(at)gmail(dot)com> |
Cc: | "pgsql-sql(at)postgresql(dot)org" <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Using Ltree For Hierarchical Structures |
Date: | 2013-02-26 19:30:27 |
Message-ID: | A76B25F2823E954C9E45E32FA49D70EC08F7BD26@mail.corp.perceptron.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
From: Don Parris [mailto:parrisdc(at)gmail(dot)com]
Sent: Tuesday, February 26, 2013 1:23 PM
To: Misa Simic
Cc: Igor Neyman; pgsql-sql(at)postgresql(dot)org
Subject: Re: [SQL] Using Ltree For Hierarchical Structures
Hi Igor,
As Misa points out, my original design used 2 tables - category & line-items. Either way it's two tables. The biggest difference lies in the approach to summing line-items by various levels of category - with each branch of the tree having different levels.
I cannot speak to performance, but understanding CTEs has been difficult for me. Ltree is so much simpler. I am certain there is a place for CTEs, but why torture myself trying to hash out a CTE when ltree makes the queries so much easier to write?
Don,
To answer this question...
Before I worked (mostly) with Oracle which has "connect by" construct to work with hierarchies.
So, when I switched to Postgres I was happy to find "connect_by" contrib. modul.
And with more recent PG versions, it was just natural transition from contrib. module to recursive CTEs.
Igor
From | Date | Subject | |
---|---|---|---|
Next Message | Don Parris | 2013-02-26 21:54:53 | Re: Using Ltree For Hierarchical Structures |
Previous Message | Thomas Kellerer | 2013-02-26 18:43:32 | Re: Using Ltree For Hierarchical Structures |