フィーチャ・オプション
ではないか
これは単なる具体例の一つに過ぎない
feature optionとはなんなのか
なにがfeatureなのか
具体的にどういう課題を解決しているのか
アイテムのコード自体には特徴情報を含めず、代わりにアイテムの「フィーチャ」や「オプション」といった別テーブルで特性を管理する方法
アイテムの種類が増えても管理が容易になり、コード体系の複雑化を避けられる
GPT-4.icon
フィーチャ・オプションの具体例
例1: 商品管理のケース
「品目」ごとに異なる特徴（フィーチャ）を「フィーチャテーブル」に定義します。
例えば、目、鼻、口といった顔の特徴を表すフィーチャを設定し、アイテムごとに「パッチリ目」「垂れ目」などのオプション値を設定可能にします。
このフィーチャ・オプションの関係を使って、各品目の特徴を細かく管理します。
https://gyazo.com/65f555b456b1a77aefe69d97643a870b https://xtech.nikkei.com/atcl/nxt/column/18/01195/072600064/?P=3
大分類としての品種
これは品種テーブルで管理する
品種の内容は、このテーブル内で決める
品種ごとに複数のフィーチャの組み合わせをあらかじめ定義しておく
フィーチャってなんやねんｎmrsekut.icon
「フィーチャ」とは目や鼻や口といった「顔を特徴づける要素（造作）」を意味する。
そして品目ごとのフィーチャに対して「オプション値」が与えられる。フィーチャが「目」であれば、そのフィーチャを持つ「品目」に対して設定可能なオプション値として、パッチリ目、垂れ目、キツネ目などが規定される。
例が微妙に分かりづらいが、
フィーチャは、品種と直交した分類みたいな？
オプションは、フィーチャに対する小分類
このオプションの妥当性を評価するために3つの関数を使う
これがvalidationとして機能するということかmrsekut.icon
妥当性の評価というより、制約といったほうがわかりやすい
予め定義していたこの制約を満たさないものは新たに登録できない
品種別フィーチャテーブルで、その組み合わせを管理する
フィーチャコード
フィーチャ名
オプション評価式
品目テーブル
個々の製品, SKU
大分類である品種をID経由で参照する
例2: 設備管理のケース
各設備タイプ（サーバ、PC、電源装置など）ごとに必要な管理属性を「モジュールタイプ別管理属性」テーブルで定義します。
設備が「サーバ」の場合、OSやCPUなどの特定属性を必要とし、「電源装置」では異なる属性（電圧や出力など）を持たせます。
このように、設備の特性に応じて管理属性を柔軟に設定し、各属性には「評価式」を用いて妥当性検査を行います。
https://gyazo.com/0b69636045d1b5bee45ecb681bdd889a https://watanabek.cocolog-nifty.com/blog/2020/04/post-2493f9.html
設備をモジュールタイプに分ける
そのモジュールタイプごとに別々の属性を管理できる
内容がよくわからない
モジュール
モジュール構成
モジュール属性明細
モジュールタイプ
評価式と妥当性検査
フィーチャ・オプションでは「評価式」による妥当性検査が行われます。
これは、以下の3つの関数で構成されます。
Range
数値範囲や増分を指定
e.g. 1から2000までの数値範囲
List
許容する値をリストとして指定
e.g. 100, 200, 300のいずれか
Script
他のフィーチャ値に基づく複雑な判定
e.g. 条件に基づいて特定の色のみ許可
これにより、データが不正な値を持たないようにし、管理者や利用者がエラーに気づける仕組みになっています。これをコードではなくデータベース上の「評価式」として保持することで、管理の柔軟性が増し、保守の負担も軽減されます。
フィーチャ・オプションの意義と利点
このパターンを導入することで、以下のような利点があります。
コード体系の単純化:
アイテムの特性をコードに組み込まず、フィーチャ・オプションで柔軟に管理できるため、コード体系が複雑化しません。
データの一貫性と保守性向上:
データベースで評価式を保持するため、保守が容易で、特性の追加や変更も簡単に行えます。
新規タイプの対応も容易:
新たなフィーチャやオプションが発生しても、データベース上で管理できるので、開発工数が少なく対応可能です。