Open1
DBやDataの id について
まさぴょん🐱id ついて
- id の命名は、task_id や user_id など具体化したが方が、明確であり可読性が上がる。
- id のデータ型は、文字列型の方が柔軟性・拡張性が高い
- 文字列の id データの生成は、ULID がおすすめ
id の命名について
Data のプロパティ名で id は task_id や user_id など具体化するべきか？
結論
-
一般的にはより具体的な名前を使用する方が、より堅牢で拡張性のあるアプリケーション開発に繋がるため
task_idやuser_idのように具体化することをお勧めします。 -
データのプロパティ名を具体的にするかどうかは、そのデータが使われる文脈やシステムの構造によって違います。
-
id を
task_idやuser_idのように具体的な名前にすることにはいくつかの利点があります。
メリット
-
明確性と可読性
- task_id や user_id のように具体的な名前を使うと、データが何を指しているのかが直感的に理解しやすくなります。
- これにより、コードの可読性が向上し、エラーの発生率も低下します。
-
バグの防止
- 複数の異なる種類の ID がプログラム内で扱われる場合、それぞれを区別するために具体的な名前を使用することで、誤って違う種類の ID を混同するリスクを減らすことができます。
-
スケーラビリティ
- システムが拡張される際に、新たな種類の ID が導入されることがあります。
- このとき、既に具体的な名前が使われていると、新しい ID を追加しやすくなり、整合性を保ちやすくなります。
id のデータ型について
Data のプロパティで、task_id や、user_id などの id は、数値にすべきか、文字列にすべきか？
-
ID 属性、例えば task_id や user_id をデータのプロパティとして使用する際、数値型と文字列型の選択はその使用目的とシステム要件によります。
-
具体的には、以下の考慮事項があります：
-
整合性と操作について
- 数値 ID は、並び替えや比較が直感的かつ効率的です。
- しかし、ID が単純に識別のためだけでなく、特定のフォーマットを必要とする場合（例えば、特定の桁数やプレフィックスを持つ ID）は文字列が適切です。
-
システム間の整合性
- 外部システムとの整合性を保つために、ID のデータ型を選択することが必要な場合があります。
- 例えば、他のシステムで文字列として ID を扱っている場合は、互換性を保つために文字列を選択すべきです。
-
拡張性
- 将来的に ID のフォーマットが変更される可能性がある場合
- 例えば、数字のみからアルファベット含む形式への変更）、文字列型の方が柔軟性が高く、変更が容易です。
一般的に、ID は内部的な処理や計算に使う場合は数値型が効率的ですが、ID が外部的な意味を持つ（例えば、ユーザーが見たり入力したりする）場合は、柔軟性とフォーマットの規定を考慮して文字列型を選択することが推奨されます。
id の文字列、生成はどんなデータいいのか？ UUID か ULID？
結論
- Sort もできる ULID が Best
JavaScript/Node.js で UILD を生成する
UUID を使ってたけど、ソートできる ULID を使いたくなったので、
探していたら、ulid を見つけたので試してみた。
npm install --save ulid
import { ulid } from "ulid";
ulid(); // 01ARZ3NDEKTSV4RRFFQ69G5FAV
// seed timeを指定する場合
ulid(1469918176385); // 01ARYZ6S41TSV4RRFFQ69G5FAV