productdb.json: 製品データの単一信頼源

この記事では、productdb がすべての製品データの単一信頼源として機能し、コンポーネント、機能、互換性ルール、部品表を一元的なファイルで定義する方法について説明します。

問題点：分散した製品データ

製品データは複数のシステムに分散している可能性があります：

在庫システム: 部品コストと在庫レベル
ERPシステム: BOMと製造データ
ウェブサイト: 製品説明と仕様
会計システム: 価格設定とコスト計算ルール

データが分散すると、不整合が発生します：

ウェブサイトは16GB RAMと表示しているが、ERPでは8GBと表示
価格設定で古いコストデータを使用
BOMが実際の製品と同期していない
機能が現実と一致しない

すべてのシステムが参照する単一の信頼源が必要です。

解決策：productdb.json

productdb.json は、すべてのコンポーネント、その機能、互換性ルール、構成要素を定義する JSON ファイルです。すべてのシステムは起動時にこのファイルを読み込みます。

このファイルはGitでバージョン管理され、すべての変更が追跡・監査可能です。

ファイル構造

ファイルはコンポーネントカテゴリ別に整理されています：

{
  "Chassis": { ... },
  "Board": { ... },
# ... (実装詳細は省略)

各カテゴリには、プロパティを持つコンポーネントが含まれています。

コンポーネント定義

各コンポーネントには複数のプロパティがあります：

基本プロパティ

class: 互換性マッチングのためのコンポーネントクラス

"class": "THIN_MINI_ITX"

internal: 在庫と製造のための内部名称

"internal": "Chassis, Treo"

external: ウェブサイトとマーケティング向けの顧客向け名称

"external": "Thinvent® Treo Mini PC"

weight: グラム単位の物理的重量

"weight": 590

互換性ルール (allows)

allows フィールドは、どのコンポーネントを一緒に使用できるかを定義します：

"allows": {
  "Board": [
    {"class": "THIN_MINI_ITX"}
# ... (実装詳細は省略)

これは以下のことを意味します：

Board: クラスが THIN_MINI_ITX のボードのみ互換性あり
Flash: クラスが m.2_SATA のフラッシュストレージのみ互換性あり
Accessories: すべてのアクセサリに互換性あり

互換性は以下の方法で指定できます：

クラスベース (動的)：

{"class": "THIN_MINI_ITX"}

部品IDベース (明示的)：

["N100", "N150", "i5-1335U"]

部品表 (constituents)

constituents フィールドは、このコンポーネントを構成する部品を定義します：

"constituents": [
  {
    "Category": "Custom",
# ... (実装詳細は省略)

これにより以下が可能になります：

コスト計算: すべての構成部品のコストを合計
製造: 組み立て用のピックリストを生成
在庫: コンポーネント使用量を追跡

機能提供 (provides)

provides フィールドは、このコンポーネントが提供する機能を定義します：

"provides": {
  "Operating Temperature": "0°C ~ 40°C",
  "Operating Humidity": "20% ~ 80% RH, non condensing",
# ... (実装詳細は省略)

これらの機能は、SKU内のすべてのコンポーネントにわたって集約され、製品の完全な仕様を作成します。

例：Treo シャーシ

{
  "Treo": {
    "class": "THIN_MINI_ITX",
# ... (実装詳細は省略)

例：N100 ボード

{
  "N100": {
    "class": "THIN_MINI_ITX",
# ... (実装詳細は省略)

productdb.json の読み込み

ファイルはアプリケーション起動時に読み込まれます：

import json

with open(PRODUCTDB_JSON_PATH, "r", encoding="utf-8") as productdb_file:
    productdb = json.load(productdb_file)

これによりメモリ内辞書が作成されます：

productdb = {
    "Chassis": {
        "Treo": { ... },
# ... (実装詳細は省略)

すべてのコードは、製品データについてこの辞書を参照します。

コンポーネントデータへのアクセス

カテゴリとIDによるコンポーネントの取得

chassis = productdb["Chassis"]["Treo"]
board = productdb["Board"]["N100"]
ram = productdb["RAM"]["8"]

外部名称の取得

name = productdb["Board"]["N100"]["external"]
# 結果: "Intel® N100 Processor"

機能の取得

features = productdb["Board"]["N100"]["provides"]
# 結果: {"Generation": "12th", "Series": "N", ...}

構成部品の取得

constituents = productdb["Chassis"]["Treo"]["constituents"]
# 結果: [{"Category": "Custom", "PartID": "base_treo", "qty": 1}, ...]

SKU検証

productdb.json を使用してSKUを検証します：

def check_sku(sku:str) -> bool:
    parts = sku.split("-")
    mapped_parts = map_parts_to_fields(parts)
# ... (実装詳細は省略)

詳細は SKU構造を参照してください。

機能集約

SKU内のすべてのコンポーネントから機能を集約します：

def get_product_features(sku: str) -> dict:
    partids = sku.split("-")
    features = {}
# ... (実装詳細は省略)

例：

SKU: Treo-N100-8-256-2H-W6-11P

機能：

- フォームファクター: Mini PC (Treoから)

- 世代: 12th (N100から)

- シリーズ: N (N100から)

- コア数: 4 (N100から)

- メインメモリ: 8 (8から)

- SSDストレージ: 256 (256から)

- HDMI: 2 (2Hから)

- オペレーティングシステム: Windows 11 Pro (11Pから)

詳細は機能抽出を参照してください。

コスト計算

構成部品のコストを合計してSKUコストを計算します：

def calculate_cost(item: dict, partid: str) -> tuple:
    if "constituents" in item:
        # 複合アイテム: 構成部品のコストを合計
# ... (実装詳細は省略)

この再帰的計算により、ネストされた構成部品を処理します。

複合アイテム

一部のコンポーネントは複合アイテム（他のコンポーネントで構成）です：

例：キーボード + マウスコンボ

{
  "KM": {
    "internal": "Keyboard + Mouse",
# ... (実装詳細は省略)

これにより以下が可能になります：

BOM生成: 必要なすべてのコンポーネントをリスト化
コスト計算: キーボード + マウス + ドングルのコストを合計
在庫追跡: コンポーネント使用量を追跡

productdb.json の更新

手動編集

ファイルはテキストエディタまたはIDEで手動編集されます。変更はGitにコミットされます：

git add PATH_TO_FILE/productdb.json
git commit -m "Add new N150 board configuration"
git push

検証

編集後、JSON構文を検証します：

python -m json.tool PATH_TO_FILE/productdb.json > /dev/null

これにより構文エラーをチェックします。

デプロイ

Gitにプッシュした後、ファイルは本番環境にデプロイされます

アプリケーションは再起動時にファイルを再読み込みします。

他のシステムとの統合

ウェブサイト

ウェブサイトは productdb.json を以下の目的で使用します：

製品ページの生成
仕様の表示
機能による製品のフィルタリング
比較表の生成

ERP

ERPは productdb.json を以下の目的で使用します：

SKUの検証
BOMの生成
コスト計算
在庫追跡

会計

会計システムは productdb.json を以下の目的で使用します：

製品コストの計算
請求書の生成
売上原価 (COGS) の追跡

SEOパイプライン

SEOパイプラインは productdb.json を以下の目的で使用します：

フレーズマッピングのための機能抽出
フィルター抽出のためのフィルター生成
機能によるクエリと製品のマッチング

詳細は SEOパイプライン概要を参照してください。

単一信頼源の利点

1. 一貫性

すべてのシステムが同じデータを使用します。不一致はありません。

2. 保守性

一度更新すれば、どこにでも伝播します。複数のシステムを更新する必要はありません。

3. 監査可能性

すべての変更はGitで追跡されます。誰がいつ何を変更したかを簡単に確認できます。

4. テスト容易性

変更は本番デプロイ前にステージング環境でテストできます。

5. 簡素さ

理解すべきファイルは一つです。複雑なデータベーススキーマやAPIはありません。

6. パフォーマンス

メモリ内辞書はO(1)ルックアップを提供します。データベースクエリは不要です。

7. 移植性

JSONは人間が読める形式で言語に依存しません。どの言語でも簡単に解析できます。

制限事項

1. 手動編集

変更には手動編集とGitコミットが必要です。非技術ユーザーのためのウェブUIはありません。

2. 再起動が必要

変更を読み込むにはアプリケーションを再起動する必要があります。ホットリロードはありません。

3. 検証機能の不足

JSON構文は検証されますが、意味的検証（例：「この部品は存在するか？」）は自動的ではありません。

4. 同時実行性

複数人が同時に編集すると、マージコンフリクトが発生する可能性があります。

参考文献

技術的概念

JSON - Wikipedia
単一信頼源 - Wikipedia
部品表 - Wikipedia

SKU構造 - ハイフン区切りSKUアーキテクチャ
機能抽出 - 機能抽出の方法
フレーズとフィルターのマッピング - フィルターのための機能の使用
SEOパイプライン概要 - 完全なパイプラインアーキテクチャ

まとめ

productdb.json はすべての製品データの単一信頼源です：

構造：

コンポーネントカテゴリ別に整理 (Chassis, Board, RAMなど)
各コンポーネントはプロパティを持つ (class, internal, external, weight)
互換性ルール (allows)
部品表 (constituents)
機能提供 (provides)

利点：

すべてのシステム間の一貫性
保守性 (一度更新)
監査可能性 (Git追跡)
テスト容易性 (ステージングデプロイ)
簡素さ (一つのファイル)
パフォーマンス (メモリ内O(1)ルックアップ)
移植性 (JSON形式)

ユースケース：

SKU検証
機能集約
コスト計算
BOM生成
ウェブサイト製品ページ
SEOパイプライン機能抽出

この一元化されたアプローチにより、すべてのシステムが同じ製品データを参照し、不整合を排除し、保守を簡素化します。

← ドキュメントインデックスに戻る

Productos

Búsquedas y artículos populares