On 2017/11/22 2:29 AM, Jens Alfke wrote:
On Nov 21, 2017, at 2:48 PM, Simon Slavin <slav...@bigfraud.org> wrote:
But that just brings us back to the question of why OP wants to store ID
numbers which might change.
When I’ve run into this before, the requirement has been to support lists with
customizable ordering, like an outliner where the user can freely drag the rows
up and down.
Oh there are many valid reasons why to have Order in data, one I use
regularly is to dictate the process flow in manufacturing where some
thing needs to go to machine Y before it can move on to machine X, or
process E, for a specific item, has to happen before process B etc.
The problem is not that "Order" by itself is silly to have in data, the
problem is that the OP intended (at first) to gain such order by
manipulating/relying on the PRIMARY KEY value expecting the DB itself to
have intrinsic order, which is folly. (A bit like changing your Surname
to adjust your place in the phone-book or indicate your position in a
race result.)
I think the OP has been swayed from this view so it is no longer a
problem. Only remaining detail is how to best maintain the order when
correctly kept as a separate entity. I think the examples already
discussed will do perfectly when implemented wisely.
Cheers,
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
