私は、アプリケーションに保存される独自のレートで通貨を交換し、クライアントトランザクションを保存し、レポート用に保存された過去の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
たぶん、私の心は奇妙ですが、私はより多くなり、この部分のための第三のスキーマオプションがあるかもしれないこの気持ちを持っています控えめな
もしあれば、私にはより良いものをお勧めしますか?
私はなぜ 'currencies_daily'テーブルが必要なのか分かりません。 rates_dailyにはまだ日付と通貨IDがあるので、3番目のテーブルは構造を複雑にしています。私は第1のスキーマに何か問題があるとは思わない - それは、為替レートを伴うほとんどのアプリケーションでの通常の設定です。ほとんどのアプリケーションは買いと売りのレートを持っていますが。 – Shadow