X-Original-To: pgsql-sql-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 88B5F9FA4E0 for ; Wed, 26 Jul 2006 21:10:09 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 59367-03 for ; Wed, 26 Jul 2006 21:09:59 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by postgresql.org (Postfix) with ESMTP id 5FC5A9FA43C for ; Wed, 26 Jul 2006 21:09:30 -0300 (ADT) Received: by nf-out-0910.google.com with SMTP id c29so4422nfb for ; Wed, 26 Jul 2006 17:09:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RikCFaNAwImdkvi4mNbaYuKeqy1t3H64xJvsrCG9miI+tX0Hi4Piww/U/9eEhHug45jNfOqeT8EUECX5dmY4fgOE9S6xmbrNXhyNoJY96o7Q6fGLFdzhJqhEipEipBI/DmWrcm1XMKLBKKGwHU0OTZka9GXi+0VpqRnuFtZOsmc= Received: by 10.78.116.19 with SMTP id o19mr3522954huc; Wed, 26 Jul 2006 17:09:27 -0700 (PDT) Received: by 10.78.153.11 with HTTP; Wed, 26 Jul 2006 17:09:27 -0700 (PDT) Message-ID: Date: Wed, 26 Jul 2006 20:09:27 -0400 From: "Michael Artz" To: "Aaron Bono" Subject: Re: Storing an ordered list Cc: pgsql-sql@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.199 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_ABUSE, SPF_PASS X-Spam-Level: X-Archive-Number: 200607/327 X-Sequence-Number: 25901 On 7/26/06, Aaron Bono wrote: > If you use the linked list, remember this: to reduce the updates you are > going to need more code in the application as it will have to keep track of > what to update and what to not update. It will also be more difficult to > order the items using SQL so your application may have to take on that > burden. As a result, your application will become more complicated and > writing reports that use the ordering will become difficult. Yeah, that was what I wanted to avoid. I wasn't sure if there was a common approach to this sort of problem. > When I need something like this I go with your first approach, a simple > order field. Unless the user is reordering a small number of items in a > very large list and doing it frequently, is there really a need to worry > about the number of updates? Are you worrying about a performance problem > you will never have? Perhaps it is unnecessary, however I wanted to start out with a decent design that could scale if need be. Also, I'd like to support "real-time" reordering, i.e. the user won't have to click "save" ... as soon as they drag the item to a new position the list is updated.