Generally speaking I avoid storing ordered data and would rather query data by time or any other aspect, but sometimes it can not be avoided. What I’ve discovered is that, at least for the data I have worked with, an order is only really needed for smaller amounts of data. So in my case it might be that I need to render page elements on a website where the page elements are defined by the user. It’s often only up to 20 or so of each element type for each user’s page. Initially I was storing the position or “spot” as I call it within each ‘ref’ item. However even at 20 items it was, relatively speaking, cumbersome to manage the code for updating relative items and their spots. So I then went with storing the ordered ids in a string at a higher level. Certainly was a better option for me considering the small amounts. Note though that I don’t currently use datomic anymore, so these days I’m storing ordered items in redis as a front to my db. Now that I’m looking at datomic again I’m deciding between that string again or keeping redis in front. Still trying to put all the pieces together for a new architecture.
Stu is right tho, I don’t query inside the list. I just grab the order and render and sometimes update the order.
Note that, IMO, one problem databases get into is providing ordered list for cases like mine (which is useful) only to have people start throwing thousands if not many more items into these ordered list only to discover the performance degrades pretty quickly when you need to insert something in the middle.