How to implement a table of ordered data ?

Question

This is surely a very common question of database design.
Let us say that I am doing a web picture gallery, where I want the pictures to appear in a specific order. I am keeping the reference of the image files in a table, and I specifically want to be able to add a new picture between any two consecutive existing pictures. Nice to have would be a fast way to move a picture to another place, and support for concurrent access.
After some tries, my best solution seemed to be something like the following, but I suspect that it is still sub-optimal :
CREATE TABLE pics(
picid NUMBER PRIMARY KEY,
filename VARCHAR2(50),
ordernum NUMBER(38,10) UNIQUE
CREATE SEQUENCE pics_picid_seq;
CREATE SEQUENCE pics_ordernum_seq;
And I populate the table by using both sequences when I add the picture at the end of the list, or by calculating the ordernum as the average between the ordernums of the two pictures between which I want to insert the new picture (saying that the -1th picture has order 0).
Two drawbacks of this implementation :
- It looks like from two concurrent inserts at the same place, one will fail to the unique constraint.
- If a very very large number of pics can be inserted or moved, I may have to create a trigger locking the table and recalculating the ordernums (well that is probably the case only for huge examples).
So what is the best solution here if concurrency support is most important ? What if insert/update speed is most important ? What if "select order by" speed is most important ? Any other criteria ?

Answer 1

I don't expect rows to be stored in any perticular order Ooops! early Monday morning misreading of your original post. My apologies.
In your solution, isn't the full table update an issue when inserting pictures at place 1 ?Well , your solution will produce a duplicate ORDERNUM in that instance, or any other instance (hint, to make averaging work you'll need to store fractions).
Yes, my eary monday morning solution may suffer poor performance if you have lots of pictures and you re-organise them a lot. It will produce prettier values for ORDERNUM, which may be helpful if you need to display it to users, but this is probably not sufficient to save my implementation.
But if you are using averages of sequences it will be even more important to use a table API. The pictures in the twenty-fifth and twenty-sixth positions might have ORDERNUM values of 19.5 and 20 respectively or - sequence caching being what it is - 134 and 137. This may be hard for users to understand. You will need to translate offset from 1 into ORDERNUM (I guess by using ROWNUM, which is not without pitfalls).
Will transactions ensure that the picture of user B won't get inserted one place before where it should ? Concurrency is a big issue. Potentially, any user inserting a single picture is affecting the whole collection. (There's also the situation where no new pictures get added but the entire collection is re-ordered). We could make an argument that the whole table ought to be locked before anything gets done. However, full table locks are usually undesirable.
One way around this is to make the users specify the picture IDs they want the new picture to appear between, rather than place. This has the advantage of being independent of prior changes, unless the prior change also inserted a picture between 25 and 26, in which case it should fail.
I suppose there probably is a canonical design solution out there, I hope someone else knows where to find it.
Cheers, APC