質問
データベース ID が「無意味」であることは経験則として適切ですか? 逆に、ID を一目で認識できるように構造化することには、大きな利点がありますか? 長所と短所は何ですか？
バックグラウンド
データベース内の ID の一貫性について同僚と議論しました。コードを変更する必要がほとんどないように、Spring を活用するデータ駆動型アプリケーションがあります。つまり、問題が発生した場合、通常はデータの変更が解決策になります。
私の主張は、ID を一貫して読みやすくすることで、長期的にはかなりの時間と頭痛の種を節約できるというものでした。ID が設定されると、頻繁に変更する必要はありません。適切に設定されていれば、将来の変更は難しくありません。私の同僚の立場は、ID は重要であってはならないというものでした。情報を ID にエンコードすることは、DB の設計ポリシーに違反しており、ID を整理するには、「時間がない」という余分な作業が必要になります。どちらの立場を支持するものもオンラインで見つけることができません。だから私はここ SA のすべての達人に目を向けています!
例
食料品店の食品を表すデータベース レコードの単純化されたリストを想像してください。最初のセットは ID にエンコードされた意味を持つデータを表し、2 番目のセットは意味を持たないデータを表します。
ID の意味:
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:
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
概要
ID の読みやすさと一貫性を維持することの長所と短所は何ですか? あなたは一般的にどちらのアプローチを好みますか、またその理由は何ですか? 業界で認められているベストプラクティスはありますか?
--------編集（ 以下のコメントからの役立つ背景情報 ）：--------
私たちのテーブルでは、主キーは常に一意の整数を含む ID フィールドです。最初は、その整数は任意でした。時間が経つにつれて、これらの ID の一部は開発者/テスターの間で自然に意味を持つようになりました。最近のリファクタリング中に、一部の開発者は、すべての ID を認識しやすくするために時間をかけました。みんなの仕事が 100 倍簡単になりました。一部の人々 (実際にはデータ/コードを使用していない) は、理論的な理由で激しく反対しました。実際には、これらの反論のどれも当てはまりません。さらに、データを使用するすべての開発者は、データの保守が大幅に容易になったことに同意しています。
私は、データ中心の環境ですぐに認識できる ID を使用することに対する正当な理由を探しています (ただし、見たことはありません)。