Les avantages et les inconvénients de rendre les ID de base de données cohérents et «lisibles» [fermés

Question

Question

Est-ce une bonne règle d'or pour que les identifiants de base de données soient "dénués de sens?" À l'inverse, y a-t-il des avantages importants d'avoir des ID structurés d'une manière où ils peuvent être reconnus en un coup d'œil? quels sont les avantages et les inconvénients?

Arrière plan

J'ai juste eu un débat avec mes collègues sur la cohérence des IDS dans notre base de données. Nous avons une application axée sur les données qui exploite le ressort afin que nous ayons rarement à changer de code. Cela signifie que s'il y a un problème, un changement de données est généralement la solution.

Mon argument était qu'en rendant les identifiants cohérents et lisibles, nous nous faisons gagner beaucoup de temps et de maux de tête, à long terme. Une fois les identifiants définis, ils n'ont pas à changer souvent et s'ils sont bien faits, les changements futurs ne seront pas difficiles. Ma position de collègues était que les ID ne devaient jamais avoir d'importance. Encoder des informations dans l'identification viole les politiques de conception de la base de données et les garder ordonnées nécessite un travail supplémentaire qui, "nous n'avons pas le temps". Je ne trouve rien en ligne pour soutenir l'un ou l'autre position. Je me tourne donc vers tous les gourous ici à SA!

Exemple

Imaginez cette liste simplifiée des enregistrements de base de données représentant des aliments dans une épicerie, le premier ensemble représente des données qui ont un sens encodé dans les ID, tandis que le second ne le fait pas:

---

ID a le sens:

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 est sans signification:

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

---

Sommaire

Quels sont les avantages et les inconvénients de garder les ID lisibles et cohérents? Quelle approche préférez-vous généralement et pourquoi? Y a-t-il une meilleure pratique de l'industrie acceptée?

-------- Éditer ( Informations générales utiles des commentaires ci-dessous ): --------

Dans nos tableaux, la clé principale est toujours un champ d'identification contenant un entier unique. Au début, cet entier était arbitraire. Au fil du temps, certains de ces ID ont naturellement pris un sens parmi les développeurs / testeurs. Au cours d'un récent refacteur, certains développeurs ont également pris le temps de rendre tous les ID plus faciles à reconnaître. Cela a facilité le travail de tout le monde 100x. Certaines personnes (qui n'utilisent pas réellement les données / code) étaient en désaccord avec véhémence pour des raisons théoriques. En pratique, aucune de ces objections ne se tient vrai. De plus, tous les développeurs utilisant les données conviennent qu'il est désormais beaucoup plus facile à maintenir.

Je recherche (mais je n'ai pas vu) un argument défendable contre l'utilisation d'ID immédiatement reconnaissables dans un environnement centré sur les données.