5

非常によく似た質問があります。知っておくべき情報が大幅に異なる製品をモデル化し、それらをラインアイテムにリンクしますか? しかし、私を助ける答えが見つかりません。

上記の Q&A の誰かが、さまざまなメタデータ情報を保持するようにデータベースを設計することを指摘しており、これには素晴らしい回答がありますが、私のプログラムでは検索機能が明示的に必要であるため、パフォーマンスが低下することは望ましくありません。

私は、PHP + Oracle を使用して、当社の販売の進捗状況を追跡し、レポートを生成する「技術者」です。ワークフローは一般的に次のようになります。

  1. マーケティング担当者は、準備されたデータ セットをシステムに提供します。
  2. 最前線のスタッフ (営業) が私のシステムで進捗状況をマークします。
    • 誰でもシステム内の結果を検索できます。
  3. 私はマーケティング担当者にレポートを作成します。

問題:

次のように、データセットの多くの列は同じです (または同じと見なすことができます)。

account|customer_name|gender|location|program_segment|...

しかし、マーケティング部門。新しいアイデアを思いつく（そして既存のものを放棄する）ように、各「販売プログラム（キャンペーン）」には独自のデータがあります。

プログラム 1 の場合、次のものが含まれる場合があります。

...|prev_coupon_code|last_usage_amount|...

ただし、プログラム 2 の場合、次のものが含まれる場合があります。

...|is_in_plan_1|is_in_plan_2|...

あなたはアイデアを得ました。

試行の失敗:

  • すべてのデータを保持するために、可能なすべてのプロパティ (列) を持つ「十分な長さ」のテーブルを使用し、空白/不要なプロパティを残していNULLました。

    しかし今では、「プロパティ」が多すぎて「販売の焦点」がさらに増えるため、「十分な長さ」になることは決してないと感じています。システムの新しいバージョン用に 41 列のテーブルの下書きを作成したところ、突然、彼らは収まらない情報を含む新しいプログラム。

  • テーブルに「ダミー列」を作成し、フロントエンドでそれらの異なる意味を「覚えておく」ことを誰かが提案しました。NUMBER(1)これは、Y/Nなどのいくつかのデータ型で機能しますDATEが、 について話すときVARCHAR2は、その数で十分かどうかわかりません...さらに、これにより、テーブルが「汚い」ように見えます。

質問：

イライラして、私は今、さまざまなプログラムにさまざまなテーブルを使用することを真剣に検討しており、UNION「今月/シーズン/年の売り上げはどうですか?」と尋ねられた場合に備えて、句を使用して大きなレポートを生成します。

技術的に、これは良い習慣ですか？実装する必要がありますか？

編集＃1：

明確にするために、1 つの「販売プログラム」は通常、放棄されるまでの数か月間実行され、実行中のプログラムごとに 1 か月あたり少なくとも 1 つのデータセットが存在します。

また、同時に複数のプログラムを実行することもできます。

編集＃2：

これらの「プログラム指定」の列にはさまざまな数があります。あるプログラムでは 10 個必要な場合もあれば、1 個しか必要ない場合もあります。

4

4 に答える 4

2

これは、正しい答えがなく、ただの応急修理の選択である状況の1つです。

XMLTypeを使用して一時的なデータ構造を保持するためにふっくらします。XMLを使用すると、プランごとにスキーマを定義できますが、XMLTypeを使用すると、データベース自体を変更する必要がなくなります。XPathクエリにインデックスを付けることができるので、パフォーマンスは引き続き良好です。 詳細をご覧ください。

1つの問題は、XMLに対してクエリを作成するのは少し難しいことですが、どちらのアプローチを採用する場合でも、厄介なクエリが問題になると思います。

于 2013-02-28T10:07:00.753 に答える
1

Oracle で文字 LOBのコンテンツにインデックスを付けることができることを認識している場合と認識していない場合があります。Oracle Intermedia/multimedia (バージョンによって異なります) を検索し、DBA に問い合わせて、利用できるかどうかを確認してください。

これにより、共通のデータ項目 (キャンペーン、開始日、終了日、&c など) の共通構造を作成し、スプレッドシート/xml データ/csv ファイルを CLOB フィールドにダンプすることが可能になります。

プレーンテキストのインデックス作成は、最初に思ったほど難しくはなく、とてもかわいいものです。

于 2013-02-28T09:45:36.920 に答える
0

別のテーブル パスをたどると、変化する列などに合わせてコードを永遠に変更することになります。

1 つのオプションは、'campaign_name'、'campaign_value' という 2 つの列を追加し、送信された列名を NAME 列に、値を value 列に入れることです。

そう、

account|customer_name|.....|campaign_name|campaign_value
'ACC001'|'Frank Burns'|........|'prev_coupon_code'|[value of prev_coupon_code

そして、あなたの2番目の例では：

account|customer_name|.....|campaign_name|campaign_value
'ACC001'|'Frank Burns'|........|'is_in_plan_1'|[value of is_in_plan_1

更新 - はい、これにはテーブルの粒度を変更する必要があるため、キャンペーンごとに一連のデータを追加します。インポートは、そこに表示される各列名のレコードを UNION するという点で少し異なり、レポートでは粒度の変更を考慮する必要があります。

スペースを完全に無駄にしているように聞こえますが、これらが Excel シートであれば、パフォーマンスは問題になりません。その場合は、テーブルをキャンペーン、アカウント、accounts_campaigns に分割する必要があります。

于 2013-02-28T09:15:25.477 に答える
0

現在の仕事では、次のシステムを 2 年間正常に使用しています。

すべての種類のレポートに共通の列で構成される「レポート」としましょう。

id - プライマリ、auto_increment。

name - レポートの名前。

次に、特定のレポートごとに、「report_marketing」などと呼ばれる別のテーブルがあります。最初のメインテーブルへの外部キーである report_id 列があります。ここで、この特定のレポートに特定の列をすべて追加します。

結果を得るには、単純に LEFT JOIN を使用します。

一部のレポートが 2 つ以上のテーブルの一部の列を共有している場合、いつでも複数の列を結合できます。

クエリの例を次に示します。

SELECT report.name, report_marketing.ammount FROM report WHERE report.type = 'M'
  LEFT JOIN report_marketing ON report_marketing.report_id = report.id;
于 2013-02-28T12:49:57.960 に答える