Pro e contro della realizzazione di ID database coerenti e "leggibili" [chiuso

Question

Domanda

È una buona regola empirica che gli ID del database siano "insignificanti?" Al contrario, ci sono benefici significativi dall'avere ID strutturati in un modo in cui possono essere riconosciuti a colpo d'occhio? Quali sono i pro e i contro?

Sfondo

Ho appena avuto un dibattito con i miei colleghi sulla coerenza degli ID nel nostro database. Abbiamo un'applicazione basata sui dati che sfrutta la primavera in modo da raramente dover cambiare il codice. Ciò significa che, se c'è un problema, una modifica dei dati è di solito la soluzione.

La mia argomentazione era che rendendo gli ID coerenti e leggibili, ci risparmiamo tempo significativi e mal di testa, a lungo termine. Una volta impostati gli ID, non devono cambiare spesso e se fatti bene, i cambiamenti futuri non saranno difficili. La posizione dei miei colleghi era che gli ID non dovrebbero mai importare. La codifica delle informazioni nell'ID viola le politiche di progettazione DB e mantenerle ordinate richiede un lavoro extra che "non abbiamo tempo per". Non riesco a trovare nulla online per supportare nessuna delle due posizioni. Quindi mi sto rivolgendo a tutti i guru qui a SA!

Esempio

Immagina questo elenco semplificato di record di database che rappresentano il cibo in un negozio di alimentari, il primo set rappresenta i dati che hanno un significato codificato negli ID, mentre il secondo no:

---

Id con significato:

Type
1 Fruit
2 Veggie

Product
101 Apple
102 Banana
103 Orange
201 Lettuce
202 Onion
203 Carrot

Location
41 Aisle four top shelf
42 Aisle four bottom shelf
51 Aisle five top shelf
52 Aisle five bottom shelf

ProductLocation
10141 Apple on aisle four top shelf
10241 Banana on aisle four top shelf
//just by reading the ids, it's easy to recongnize that these are both Fruit on Aisle 4

Id è senza significato:

Type
1 Fruit
2 Veggie

Product
1 Apple
2 Banana
3 Orange
4 Lettuce
5 Onion
6 Carrot

Location
1 Aisle four top shelf
2 Aisle four bottom shelf
3 Aisle five top shelf
4 Aisle five bottom shelf

ProductLocation
1 Apple on aisle four top shelf
2 Banana on aisle four top shelf
//given the IDs, it's harder to see that these are both fruit on aisle 4

---

Riepilogo

Quali sono i pro e i contro di mantenere gli ID leggibili e coerenti? Quale approccio preferisci generalmente e perché? Esiste una migliore pratica del settore accettata?

-------- modificare ( Informazioni utili in background dai commenti, di seguito ): --------

Nelle nostre tabelle, la chiave primaria è sempre un campo ID contenente un numero intero univoco. Inizialmente, quell'intero era arbitrario. Nel tempo, alcuni di questi ID hanno assunto naturalmente un significato tra sviluppatori/tester. Durante un recente refactor, alcuni sviluppatori hanno anche impiegato del tempo per rendere più facili da riconoscere tutti gli ID. Ha reso il lavoro di tutti 100x più facile. Alcune persone (che in realtà non usano i dati/codice) in disaccordo con veemenza per motivi teorici. In pratica, nessuna di quelle obiezioni è vera. Inoltre, tutti gli sviluppatori che utilizzano i dati concordano sul fatto che ora è significativamente più facile da mantenere.

Sto cercando (ma non ho visto) un argomento difendibile contro l'utilizzo di ID immediatamente riconoscibili in un ambiente incentrato sui dati.