From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Felix Finch <felix(at)crowfix(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Tables referencing each other |
Date: | 2003-12-19 21:07:24 |
Message-ID: | 20031219210724.GA14968@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Dec 18, 2003 at 23:46:48 -0800,
Felix Finch <felix(at)crowfix(dot)com> wrote:
>
> What I am trying to do is have a linked list, where each item record
> also points to the parent list record, and the list record points to
> the head and tail item records. Is this something not usually done in
> an RDBMS, is this symptomatic of a squirrelly design, is there a
> better way to create linked lists, should I just skip having items
> point to the parent list, since that can be found from a SELECT
> anyway? The list is singly linked, and I create it backwards to avoid
> having to DEFER the REFERENCE.
Normally using a linked list would be a bad idea. Normally when you use
a linked list, you really don't care who is lined to you; you just care
about what the set of values is. If you are storing several different
linked lists in the same table, you can just label rows with a list ID
to indicate which list a row is in. If you have some concept of order, then
you may do something to indicate the order. While their may be times you
would want to do this with a linked list, usually you wouldn't, because
ordering rows based on the links is hard to do efficiently in SQL.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-12-19 21:33:46 | Re: performance in selecting from very large recordset |
Previous Message | Robert Treat | 2003-12-19 21:00:24 | Re: PostgreSQL speakers needed for OSCON 2004 |