Question

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

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

用户每天输入一次，并手动输入每日基于1欧元出售/购买每枚硬币的货币（例如美元，英镑，澳元）汇率。例如，简单的缘故，让我们说只会设定卖出价格。

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

因此，有一些选项可以为这部分设计MySQL DB

第一个架构选项

currencies (id, name)

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

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

| ___ 将存储每种currency.name

的每日费率

由于它必须在同一个表中存储多个currency.name率，我必须通过组合日期和时间来制作一个UNIQUE键来保持数据的完整性。 currencies.id

然而，使用一个存储每日多种货币汇率的表是不正确的，如果每个让我们说20个货币汇率记录存储在同一个表中。

第二个架构选项

currencies (id, name)

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

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

| ___ 组合日期和时间的UNIQUE键currencies.id

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

| ___ 组合currency_daily.date＆amp;的UNIQUE键currencies_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)
)

我认为您希望每天为每种货币捕获的两个货币点是出价和询问价格。这两个价格决定了价差，以及购买货币时预期支付的价格，或者在卖出货币时收取的价格。

Exchange费率应用程序的数据库架构

1 个答案: