It depends on what your goal is. If you just want a simple ordering, then you can just an integer column for order, or priority, etc. But if you want columns for priority, like a kanban board, you might encode that differently by having for example an M to N mapping of issues and columns. In that case, you can also have an order or priority for your issue, so that in can be ordered correctly in the column.
Reordering by the user is a trivial problem. You would simply keep track of the original order of the issue (i.e. the integer value order); once you know the updated/new order, it’s some basic math to get all issues for that column and update their orders as well. For example, you have these 3 issues in the column named “TODO”:
- “Fix database bug” -
order = 1
- “Fix UI bug” -
order = 2
- “Implement feature” -
order = 3
you could move “Implement feature” to the top and adjust the order values for the other issues in that column to:
- “Implement feature” -
order = 1
- “Fix database bug” -
order = 2
- “Fix UI bug” -
order = 3
So, to answer the root question, it depends on your use case!
But all in all I think most people just use a simple integer column and some basic order-update logic when things get moved around. Note that this requires 1 database record update for every item that needs to have its order adjusted (in the above example, 3 records are updated). However, this shouldn’t be an issue for most relational databases as you could (and should) wrap those updates in a transaction.
