5

私たちの組織は、クライアントにさまざまなサービスを提供しています (例: Web ホスティング、技術サポート、カスタム プログラミングなど)。当社の Web サイトには、利用可能なすべてのサービスとそれに対応する価格を一覧表示するページがあります。これは静的データでしたが、上司は代わりにデータベースからすべてを取得することを望んでいます。

約100のサービスがリストされています。ただし、「価格」に数値以外の値があるのはそのうちの 2 つだけです (具体的には、「ISA」と「コスト + 8%」という文字列です。これらが何を意味するのかよくわかりません。私に聞いて）。

この 2 つのリストがあるからといって、"price" 列を varchar にするのは嫌です。私の現在のアプローチは、特別な「price_display」フィールドを作成することです。これは、空白であるか、価格の代わりに表示するテキストが含まれています。ただし、このソリューションは汚いハックのように感じられます (クエリが不必要に複雑になります)。より良いソリューションはありますか?

4

8 に答える 8

4

過去にこの種のことをしなければならなかったとき、私は使用しました：

Price   Unit   Display
10.00   item   null
100.00  box    null
null    null   "Call for Pricing"

価格は 10 進数のデータ型 (浮動小数点や実数ではなく、任意の正確な数値) であり、単位と表示は何らかの文字列データ型になります。

次に、case ステートメントを使用して、単価またはディスプレイのいずれかで価格を表示しました。また、価格が null でない限り null でなければならないように、表示列に制約またはトリガーを設定します。price が null でない場合、制約またはトリガーには単位の値も必要です。

このようにして、可能な場合は注文の価格を計算し、価格が指定されていない場合は省略して両方を表示できます。また、価格設定の呼び出しが解決されるまで合計を合計できないようにするビジネス ルールを設定します (これには、注文の詳細からプルするだけでなく、注文の詳細に特別価格を挿入する方法も必要です)。価格表）。

于 2009-07-20T19:32:24.340 に答える
4

この列は顧客に表示される価格であり、何でも含めることができると考えてください。

数値列にしようとすると、悲しみを招きます。あなたはすでに 2 つの不適合な価値観に苦しんでおり、明日あなたの上司はもっと要求するかもしれません...

  • アプリケーションの価格！
  • 今日のスペシャルはお電話ください!!

あなたはアイデアを得る。

数値列が本当に必要な場合は、それをinternalPriceなどと呼び、代わりにその列に数値制約を設定してください。

于 2008-12-05T20:48:08.220 に答える
2

自問してみてください...

これらの値を追加しますか? 値段順で並びますか？他の通貨値に変換する必要がありますか?

また

この値を Web ページに表示するだけですか?

これが単なる洗濯物のリストであり、計算に使用されない場合、最も簡単な解決策は価格を文字列 (varchar) として保存することです。

于 2008-12-05T20:48:23.510 に答える
1

おそらく、メイン テーブルで「タイプ」インジケーターを使用し、1 つの子テーブルでは数値価格を許可し、別の子テーブルでは文字値を許可します。これらを 1 つのテーブルに結合することもできますが、私は通常それを避けます。購入した数量に基づいて価格を設定したい場合は、数量を含む中間リンク テーブルを使用することもできます。

于 2008-12-05T20:38:33.403 に答える
1

多くの選択肢:

  1. varchar として保存されたすべての価格
  2. 数値で保存された価格と、入力された場合に数値を上書きする追加の price_display フィールド
  3. 数値で保存された価格と表示目的の追加の price_display フィールドは、手動で入力されるか、数値の価格が更新されたときにトリガーされます (データの重複と同期が取れなくなる可能性があります - yuk)
  4. 特別な状況に対応するストアの特別な場合のマイナス価格 (単純に yuk!!)
  5. varchar 価格、使用可能なプレフィックスのテーブルへのプレフィックス キー フィールド ('cost +'、...)、使用可能なサフィックスのテーブルへのサフィックス キー フィールド、価格の値のタイプのリストへのタイプ フィールド キー ('$' 、 '％'、 '説明'）。将来、価格に対して複雑なクエリを作成する必要がある場合に便利です。

実用的な解決策としてはおそらく 2 を選択し、一般的な価格設定システムに非常に一般的なものが必要な場合は 5 の拡張を選択します。

于 2008-12-05T20:38:50.253 に答える
1

これがデータ モデルの範囲であれば、varchar フィールドで問題ありません。あなたの通常の価格 - 10 進数かもしれません - はおそらく計算には役に立たないでしょう。「データ転送」の $10/GB と「ドメイン ホスティング」の $25/月を比較するとどうなりますか?

この特定のプロジェクトのデータ モデルは、価格に関するものではなく、価格の表示に関するものです。それを念頭に置いて設計してください。

もちろん、特定の顧客が特定のプロジェクトに支払った価格を保存している場合、または特定の顧客に請求する金額を把握しようとしている場合は、別の (より複雑な) ドメインを使用します。また、それをサポートするには別のモデルが必要になります。

于 2008-12-05T20:50:06.720 に答える
1

代替価格の少なくとも 1 つに数値が含まれているという点で、Price 列、価格タイプはどうでしょうか? 通常のエントリは、ドルの値とタイプ「dollar」の数値であり、もう 1 つのエントリは 8、「PercentOverCost」、null、および「ISA」 (Price および PriceType 列の場合) です。

この方法を使用する場合は、おそらく検証する PriceType テーブルと PriceTypeID が必要です。

これにより、将来的に他のタイプの価格設定 (単位価格設定、外国通貨) を追加できるようになり、数値が得られ、扱っている価格設定のタイプを簡単に知ることができます..

于 2008-12-05T21:06:30.697 に答える