2017-04-26 11 views
0

私は、アプリケーションに保存される独自のレートで通貨を交換し、クライアントトランザクションを保存し、レポート用に保存された過去の1日の金利を維持する小規模会社のカスタムWebアプリケーションを開発しています。 、為替レートのデータベーススキーマ

  • ユーザ入力、毎日一回、手動で通貨(例:USD、GBPのために:。

    私はMySQLの DBを設計しようと思っている第一の機能部分は以下のとおりです。 AUD)の為替レートで、毎週1ユーロに基づいて各コインを売買します。たとえば、簡単に言うと、販売レートが設定されているとします。

  • 毎日の料金は、履歴レポートで使用されるためにDBに残され、翌日のもので上書きされません。

だから、この部分

まずスキーマオプション

currencies (id, name) 

のためのMySQL DBを設計するためにいくつかのオプションがあります| ___がそれぞれの独自の略称名が存在しますコイン(USD、GBPなど)

rates_daily (id, date, currencies.id[fk], net_price, fee, total_price) 

| ___は、同じテーブル内の複数のcurrencies.name率を保存するために持っているので、私は組み合わせて、一意のキーを作成することにより、データの整合性を維持する必要があり、各currencies.name

の日常率が保存されます日付&通貨.id

しかし、毎回複数通貨の通貨を貯蓄する1つのテーブルを使用することは、すべての通貨レートのレコードが同じテーブルに格納されているとすると膨大になります。

第二に、スキーマオプション

currencies (id, name) 

| ___ UNIQUEキー| ___各コイン(USD、GBP、など)

currencies_daily (id, date, currencies.id[fk]) 

のユニークな名前があるでしょう日付を組み合わせることにより&通貨.id

rates_daily (id, currencies_daily.date[fk], currencies_daily.currencies.id[fk], net_price, fee, total_price) 

| ___はcurrencies_daily.date &を組み合わせることで UNIQUEキーがcurrencies_daily.currencies.id

たぶん、私の心は奇妙ですが、私はより多くなり、この部分のための第三のスキーマオプションがあるかもしれないこの気持ちを持っています控えめな

もしあれば、私にはより良いものをお勧めしますか?

+0

私はなぜ 'currencies_daily'テーブルが必要なのか分かりません。 rates_dailyにはまだ日付と通貨IDがあるので、3番目のテーブルは構造を複雑にしています。私は第1のスキーマに何か問題があるとは思わない - それは、為替レートを伴うほとんどのアプリケーションでの通常の設定です。ほとんどのアプリケーションは買いと売りのレートを持っていますが。 – Shadow

答えて

1

第2のオプションは、不要な第3のテーブルをスキーマに追加する点を除いて、最初のオプションよりも利点がありません。ここで私が使用するものです。

CREATE TABLE currencies (
    id INT NOT NULL AUTO_INCREMENT, 
    name VARCHAR(55) NOT NULL, 
    PRIMARY KEY (id) 
) 

CREATE TABLE rates_daily (
    id INT NOT NULL AUTO_INCREMENT, 
    date DATETIME NOT NULL, 
    currency_id INT NOT NULL, 
    bid NUMERIC (15, 2) NOT NULL, 
    ask NUMERIC (15, 2) NOT NULL, 
    FOREIGN KEY fk_curr (currency_id) 
    REFERENCES currencies (id) 
) 

私はあなたが各通貨のためにキャプチャしたいと思う2つの金銭のポイントは、それぞれの日に、価格を尋ねる入札です。これらの2つの価格は、スプレッドを決定し、通貨を購入するときに支払うと予想される金額や、通貨を売るときに受け取る金額を決定します。

関連する問題