汇率应用程序的数据库架构

Question

我正在为一家小公司开发自定义Web应用程序，该公司将使用自己的汇率交换货币，该汇率将存储在应用程序中，将存储客户交易记录，并保留过去的每日汇率以供报告。

我要为其设计MySQL DB的第一个功能部分是：

• 用户每天输入一次，然后手动输入货币（例如，USD，GBP，AUD）汇率，该汇率将每天以1欧元为基础买卖每个硬币。 例如，为简单起见，假设只设置了卖出率。
• 每日费率将保留在数据库中供历史报告使用，并且不会被第二天的费率覆盖。

因此，有一些选项可以设计这部分的MySQL数据库

第一个方案选项

currencies (id, name)  

| ___每个硬币都有唯一的缩写名称（USD，GBP等）

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

| ___将存储每种货币的每日汇率。

由于它必须在同一表中存储多个currency.name费率，因此我必须通过结合date＆currency.id来创建UNIQUE键来保持数据完整性。

但是，如果每个人都说有20个货币汇率记录存储在同一张表中，那么使用一个表存储多种货币的每日汇率将显得不正确。

第二个方案选项

currencies (id, name)

| ___每个硬币都有唯一的名称（美元，英镑等）

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

| ___ UNIQUE键，通过组合date和currency.id

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

| ___ UNIQUE键，通过组合currency_daily.date和currencys_daily.currencies.id

也许我的想法很怪异，但是我有一种感觉，这部分可能会有第三个模式选项，它将更加简洁。

如果有的话，您能推荐我一个更好的吗？

Answer 1

据我所知，您的第二个选项没有一个比第一个选项有任何优势，只是在架构中添加了不必要的第三个表。 这是我可能会使用的：

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)
)

这两种货币的点我想你想捕捉每一种货币，在每一天，是买入价和卖出价。 这两个价格决定了点差，也决定了购买货币时期望支付的价格或出售货币时期望获得的价格。