前回は単純に値一覧で管理している元号を元にカスタム関数を使って和暦を西暦に変換しました。
今回は、もう少しシステムのマスタ管理をする人とシステム開発者が楽ができるような設計です。
動き
動きは前回と変わりません。
和暦を選択し、和暦で年月日を入力すると、、、
和暦・西暦で展開します。
実装
概要
元号マスタを管理し、実際に使うテーブルの和暦とリレーションシップをとります。
元号マスタ
元号マスタとして管理するのは、以下の通りです。
ここでのポイントは、表示順を持つことです。
値一覧で表示順でソートをして表示します。
表示順も表示されてしまいますが、表示順を隠す方法は今回の記事とは関係ありませんので割愛します。
データは単純に元号に関するデータのみです。
元号マスタとのリレーションシップ
前回作成したテーブルのデータ構造を壊したくないので、新たにフィールドを追加しました。
役割としては、前回のものとほぼ同じです。
違う箇所は、今回の和暦フィールドは数字として持ち、これを元号マスタの表示順と紐付けるところです。
リレーションシップを表示順にすると、表示順が違ってしまったらどうする、、、との声もありそうですが、今回は元号という順番が入れ替わらないものですのでこのままで。
値一覧の設定
値一覧は、ソート順を表示順にすることを忘れずに設定します。
レイアウト上の設定とスクリプト
レイアウトに配置したフィールドも前回と特に変わりません。
違うのは、フィールド名と指定するスクリプトです。
スクリプトトリガで設定するスクリプトは、単純にフィールド設定のみとなります。
元号マスタとリレーションシップをとっているため、元号の略称を引っ張ってこれます。
マスタ化するかどうかの判断について
マスタ化するとなると、メンテナンスするテーブルやデータが増えることになりますので、できればそういうのが無いように実装したいと思う気持ちがあるかもしれません。
確かにそうですが、マスタ化しないことでメンテナンスするスクリプトや関数が増えることの方がリスクが大きいと思います。
スクリプトを１箇所変更するだけで、全てに影響がないかどうかを確認する必要があるからです。
マスタ化していたら、マスタのデータ増減で正しく計算ができているかどうかの確認も必要ありません。（厳密にはあるけれど。。。）
マスタ化で気をつけるところは、不要な元号が入り込まないようにするだけです。
ただ、現場の状況やシステムの大小でマスタ化をしなくてもいい場合もありますので、適宜実装を考慮してください。