/note/tech

コードをintで持つかstringで持つか論争

マジックナンバー int だらけのレガシーなデータベースを Laravel でさばく方法

1. Eloquent Model に

public const MODE_FOO = 1;

のように定数を定義

2. JsonResource に

public const MODES = [

Model::MODE_FOO => 'foo',

];

みたいなマッピングを定義

@mpyw

FormRequest では Rule::in(JsonResource::MODES) でバリデーション可能,そのあと array_search($this->input('mode', JsonResource::MODES) で数値化できる

JsonResource::toArray() では static::MODES[$this->resource->mode] で文字列化できる

@mpyw

これはあくまで既存の闇データベースを新規 API で綺麗に見せるときのテクニックです。

新規データベースに関して Excel で数値と意味の対応表を作っているエンジニアが居たら爆破しましょう。

@mpyw

社内の文化的に普通に数値でDBに入れてるな……(DBに文字入れちゃうと名前変えずらくなるし)

(Enum使って変換かけてるから気になったことないし……)

@civil_destroyer

「名前を変えづらい」

「数値に変な欠番とか飛び番ができる」

「バックエンドとフロントエンドでの変換ロジックの共通化が難しい」(TypeScript 以外)

のトレードオフ。命名しっかりしてれば前者のほうがマシかと思ってる

@mpyw

データ量が多くならない想定で、多言語対応もなく改修もあまり見込まれないプロダクトならあり。

それ以外だと躊躇するなぁ。

@bukkan817

個人的にはフロントでそのまま表示できる文字列で保持するのがわかりやすくて好きやけど、経験則としてはコード値(整数)で保持したい人が多かったかな。

クエリの速度的な意味でそうしてるのかと認識してるけど、ユーザーの操作でレコード増えないのでわかりやすさ優先で良いと思ってる。

@isao_e_dev

・Aurora みたいな分散データベース使ってたらストレージ使用量のことはほぼ気にしなくていい

・フィールドには英語を書くんじゃなくて論理名を書くだけなので多言語対応の有無は全く関係ない

なのでむしろ特別な理由なくフロントエンドを苦しめやすい数値を使うほうが躊躇する

@mpyw

これなんで伝わらないんですかね?(否定的な反応に困惑)

個人的には「文字列が良いに決まってる」くらいの感じなんですが

変数名に「1」とか「2」とか付けたら後から把握大変だよね?と同じような話だと思っています

@dyoshikawa1993

この辺で「綴り間違えたデータがまぁまぁ散見された」とか「日本語で入ってるんだけど、長音の文字コードが複数散らかってた」とか色々見てるから、文字列は文字列で、わりと躊躇するんだよなぁ………

https://twitter.com/mpyw/status/1298186910981148675

@gallu