Dipende da qual è il tuo obiettivo. Se desideri semplicemente un ordinamento semplice, puoi solo una colonna intera per order , o priority , ecc. Ma se vuoi colonne per priorità, come una scheda kanban, potresti codificare in modo diverso avendo ad esempio una mappatura da M a N di issues e columns . In questo caso, puoi anche avere un order o priority per il tuo issue , in modo che possa essere ordinato correttamente nella colonna.
Il riordino da parte dell'utente è un problema banale. Dovresti semplicemente tenere traccia dell'ordinamento originale del problema (cioè il valore intero order ); una volta che conosci l'ordine aggiornato / nuovo , è un po 'di matematica di base ottenere tutti i problemi per quella colonna e aggiornare i loro ordini. Ad esempio, hai questi 3 problemi nella colonna denominata "TODO":
- "Correggi bug del database" -
order = 1
- "Correzione bug UI" -
order = 2
- "Implementa funzionalità" -
order = 3
potresti spostare "Funzione attrezzo" in alto e modificare i valori dell'ordine per gli altri problemi in quella colonna:
- "Implementa funzionalità" -
order = 1
- "Correggi bug del database" -
order = 2
- "Correzione bug UI" -
order = 3
Quindi, per rispondere alla domanda radice, dipende dal tuo caso d'uso !
Ma tutto sommato penso che molte persone usino semplicemente una semplice colonna intera e una logica di aggiornamento degli ordini di base quando le cose vengono spostate. Nota che richiede 1 aggiornamento del record del database per ogni articolo che deve essere regolato per l'ordine (nell'esempio sopra, 3 record vengono aggiornati). Tuttavia, questo non dovrebbe essere un problema per la maggior parte dei database relazionali come potresti (e dovrebbe ) avvolgere quegli aggiornamenti in una transazione.