On 7/26/06, Aaron Bono <postgresql@aranya.com> 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.