私は現在、製品の新しいセクションを開発するためのデータベース設計段階にあります。セットアップのいくつかの部分についてあまり自信がないので、「健全性チェック」またはアドバイスが必要です。
少しの背景情報
私たちが開発している製品は、いわゆる「マーケティングROI最大化システム」です。ビッグデータを処理し、さまざまなマーケティングチャネルに送信する前に、膨大な量の情報を処理/強化/強化します. それは基本的に一言で言えばそれがすることです。
問題のドメイン
このシステムは現在、データの適切な検証機能を十分に備えておらず、「マーケティング」担当者や「セルフサービス」顧客と呼ばれるものによって日常的に「悪用」されています。Google の新しい商品リスト広告ネットワークを当社の CEO が念頭に置いているため、Google のショッピング チャネル (PLA と呼びます。商品リスト広告）。
これが問題です:
当社の製品はいかなる形式の検証も提供せず (読み取り: ネットワーク固有の要件への準拠)、PLA は基本的に、アイテムの分類 (各カテゴリには必須/オプション フィールドが定義されています) によるデータの完全性を中心に展開しています。また、各フィールドは特定の形式にすることができます。
ご想像のとおり、私たちは現在のセットアップにちょっとうんざりしています。このような「厳密な」商品フィードを強制することは不可能です。マーケティング担当者とセルフサービスの顧客がデータを作成して PLA に送信できるようにすることで、99% の確率でバグハンティング/問題解決を行うことができます。小さな会社なので、本当の問題に目を向けたいと思います。つまり、PLA のマーケティング キャンペーンに使用できる実際の検証システムを作成しようとしています。
何をする必要があるか
私はマーケティング担当者や顧客と話をして、ユースケースとは何か、要件は何かを知りました。これらは、次のリスト項目に要約できます。
- 入力フィードの各アイテムは、Google PLA カテゴリに「分類」してマッピングする必要があります (どのカテゴリにマッピングできるかについては、「リンク」セクションを参照してください。
- 検証は、「カテゴリ」ごとにフィールドごとに設定する必要があります
- アイテムごとの各フィールドは、選択したカテゴリで定義されたフィールドに割り当て/マップする必要があります。
追加のサイド情報
さて、「「アイテム」を「カテゴリ」に、または「フィールド」を「カテゴリ フィールド定義」にどのようにリンクするか、またはそのようなことについて心配したくありません。これらの「動的なもの」は、によって処理されます。別の機会に開発される ECA ルール システム (なぜあなたが尋ねるのですか? システムはスケジュールに基づいてデータを処理/処理しているため、後で使用するために各操作を定義して保存する必要があります)、実装の詳細について心配する必要はありません。今のところ。
また、具体的な特定の実装は、多くの場合、動的属性 (たとえば、データ型によって定義されるフィールドの属性など) を使用して実現されます。EAV システムも、今のところ私の主な焦点ではありません。(上記の使用例は、データベースの設計を見れば、より理にかなっています)。
私の現在のデザイン
まず、主なエンティティを使用して SQL 構造を説明しましょう。
schemas; 「カテゴリー」を定義する抽象的な方法、PLA カテゴリーを考えてみましょうfields; フィールド定義 ( 内schema)datatypes; タイプのバッグ。(主に、上記のフィールドにデータの整合性を与えるために使用されます)valueConstraints; 制約定義のバッグ (実装ではありません!)。
今。これまでのところ、すべてがうまくてダンディです。ちょっと気になる点は以下です。
valueConstraintsN:M テーブル ( ) によってデータ型にバインドされていdatatype_valueConstraintsますが、ほとんどすべてのユーザーが生成したデータ型は、利用可能な値制約のサブセットのみで構成されています。 「電子メール」制約..しかし、価格が常に数値であることを考えると、「最小」および「最大」制約を持つことは理にかなっています。わかりやすくするために、データ型ごとdatatype_valueConstraintsに「可能性」を保持しています。valueConstraints
PrimitiveType -> constraintValue の関係でも同じ問題が発生します。基本的に、データ型には「primitiveType」(私の場合はプリミティブ型テーブルへの外部キー) が含まれている必要があります。プリミティブ型は、選択する を管理valueConstraintsします。primitiveTypesユーザー生成とvalueConstraintsは見なされないため、現時点ではフィクスチャ データです。
わからない？ワークフローの例を次に示します (「PLA/clothing」スキーマの (部分的な) セットアップ):
- データタイプ「画像」を追加し、{プリミティブ タイプを TEXT} に設定します
- 使用する以下
ValueConstraintsを選択します (TEXT 固有)- 「URL」（http|https などであることを確認してください）
- 「MinLength」（そこにあることを確認してください）
- 「正規表現」（特定の画像拡張子を許可する..またはそのようなもの）
- 使用する以下
- フィールド定義「imageURL」を追加し、{datatype を「image」} に設定します。
- データ型固有の構成、つまり、制約アサーション データ (EAV パターン関連) を入力します。"MinLength" = 14、"Regex" = "*(gif|jpg|png)" など。
データ型がプリミティブな「TEXT」であったため、ユーザーは「TEXT」関連のみから選択できました (そして、ツリーのようなデータ型システムのために継承されました) valueConstraints。
データ型が適切に設定されると、スキーマ内の複数のフィールドにデータ型 "image" を使用できます (必要な場合)。例えば; 「PLA/CLOTHING」スキーマには、「追加の画像」フィールドが必要になる場合があります。これは、おそらく別の制約構成で「画像」データ型を再利用することで完全に可能になりました。
関係を示す視覚的な SQL テーブル レイアウト (テキストの壁の上に関する脳波):
私のDBスキーマ: (クリックして拡大)
TLDR;
「私の現在のデザイン」をご覧になり、ご意見をお聞かせください。複雑すぎる/よく考えられておらず、改善を求めている可能性があると思います。注: 私は DBA ではなく、単なる開発者です。(また、「問題のドメイン」セクションを読んでいない場合、スキーマ設計が意味を成すかどうかもわかりません:P)
リンク
皆さんがどう思うか、とても楽しみです。前もって感謝します！