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

【问题标题】：Database schema for Exchange rates application汇率应用程序的数据库架构
【发布时间】：2017-04-26 09:36:58
【问题描述】：

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

我要为其设计 MySQL 数据库的第一个功能部分如下：

用户每天手动输入一次货币（例如美元、英镑、澳元）汇率，每天以 1 欧元为基础出售/购买每枚硬币。例如，为了简单起见，假设只设置卖出价格。

每日汇率将保留在数据库中以用于历史报告，并且不会被第二天的汇率覆盖。

所以有一些选项可以为这部分设计 MySQL 数据库

第一个架构选项

currencies (id, name)

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

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

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

由于它必须在同一个表中存储多种货币。名称汇率，我必须通过组合日期和货币的唯一键来保持数据完整性。id

但是，如果每个比方说 20 种货币的汇率记录都存储在同一个表中，那么使用一个存储多种货币每日汇率的表会很不合适。

第二个架构选项

currencies (id, name)

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

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)

|___ 唯一键，结合 currency_daily.date 和 currency_daily.currencies.id

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

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

【问题讨论】：

我完全不明白您为什么需要currencies_daily 表。您的 rates_daily 仍然有日期和货币 ID，因此第三张表只是使您的结构复杂化。我认为第一个模式没有任何问题 - 这是大多数汇率应用程序中的常见设置。尽管大多数应用程序都有买入和卖出价格。

标签： mysql database schema

【解决方案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)
)

我认为您希望在每一天为每种货币获取的两个货币点是 bid 和 ask 价格。这两个价格决定了价差，以及购买货币时预期支付的金额，或出售货币时预期收到的金额。

【讨论】：