X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 92EB53A5201 for ; Mon, 29 Nov 2004 19:13:26 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 63090-06 for ; Mon, 29 Nov 2004 19:13:22 +0000 (GMT) Received: from mail.travelamericas.com (unknown [206.130.134.147]) by svr1.postgresql.org (Postfix) with SMTP id A5BD43A51E4 for ; Mon, 29 Nov 2004 19:13:19 +0000 (GMT) Received: (qmail 1955 invoked from network); 29 Nov 2004 19:13:15 -0000 Received: from unknown (HELO ?10.0.0.253?) (10.0.0.253) by verkiel.travelamericas.com with SMTP; 29 Nov 2004 19:13:15 -0000 Message-ID: <41AB74CB.5050805@metatrontech.com> Date: Mon, 29 Nov 2004 11:13:15 -0800 From: Chris Travers User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Knopp , pgsql-sql Subject: Re: Way to stop recursion? References: <41A79A2A.6070606@delegated.net> <19345.1101504671@sss.pgh.pa.us> <41A7A5C2.6080800@delegated.net> In-Reply-To: <41A7A5C2.6080800@delegated.net> Content-Type: multipart/mixed; boundary="------------060900020205010304020906" X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200411/291 X-Sequence-Number: 19609 This is a multi-part message in MIME format. --------------060900020205010304020906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jonathan Knopp wrote: > > Sorry, I should have mentioned that there is a lot more to the design > that makes this replication necessary, including another two levels to > the tree plus the ability to have orphaned children. > My first thought was "Dude, use a VIEW...." In database design, the SPOT principle applies. *Always* enforce a Single Point Of Truth. If that doesn't seem to be possible, rethink how the data is used and look at how to ensure that there is only ONE authoritative storeage for each piece of transactional data. (Yes, sometimes we get away from this with OLAP installations but the data is not generally being updated there.) In this case, I would create a view (with appropriate rules) which would automatically populate the common fields from the parent if it exists. The issue should not be one of storage but of presentation. Best Wishes, Chris Travers Metatron Technology Consulting > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > --------------060900020205010304020906 Content-Type: text/x-vcard; charset=utf-8; name="chris.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="chris.vcf" begin:vcard fn:Chris Travers n:Travers;Chris email;internet:chris@metatrontech.com x-mozilla-html:FALSE version:2.1 end:vcard --------------060900020205010304020906--