这可能听起来像一个愚蠢的问题,但在这里;我相信这里的任何人都发生了这样的事情,你构建了一个每个规范都有数据库结构的web应用程序(php / mysql),但是规格略有改变,你需要在db中进行更改以反映它,这里是一个简短的例子:
Order table
->order id
->user id
->closed
->timestamp
但由于订单的付款方式与数据库中引用的货币不同,我需要添加字段exchange rate
,仅在关闭订单时检查并知道,而不是在插入时的记录。因此,我可以将新字段添加到当前表中,并在插入时将其保留为空/空,然后在必要时更新;或者我可以创建一个具有以下结构的新表:
Order exchange rates
->exchange id
->order id
->exchange rate
虽然我认为这封信更好,因为它是一个不太干扰的变化,并且不会影响其他应用程序功能,但最终可能会收到疯狂的联合查询以获取所需的所有信息。另一方面,前一种方法可能会破坏数据库中的其他一些查询,但它在整体数据库结构方面肯定更实用,也更符合逻辑。另外,我不认为使用insert null结构并稍后更新是一个好习惯,但这可能只是我孤独的看法...... 因此,我想问一下你认为最好的方法是什么。
答案 0 :(得分:1)
我想到了另一种选择。设置汇率表,如:
create table exchange_rate(
cur_code_from varchar2(3) not null
,cur_code_to varchar2(3) not null
,valid_from date not null
,valid_to date not null
,rate number(20,6) not null
);
alter table exchange_rate
add constraint exchange_rate_pk
primary key(cur_code_from, cur_code_to, valid_from);
该表应包含类似以下内容的数据:
cur_code_from cur_code_to valid_from valid_to rate
============= =========== ========== ======== ====
EUR EUR 2014-01-01 9999-12-31 1
EUR USD 2014-01-01 9999-12-31 1,311702
EUR SEK 2014-01-01 2014-03-30 8,808322
EUR SEK 2014-04-01 9999-12-31 8,658084
EUR GBP 2014-01-01 9999-12-31 0,842865
EUR PLN 2014-01-01 9999-12-31 4,211555
请注意转换为相同货币时的特殊情况。
从标准化的角度来看,您不需要valid_to
,因为它可以从下一个valid_from
计算,但从实际的角度来看,它更容易使用有效的select o.order_value * x.rate as value_in_customer_currency
from orders o
join exchange_rate_t x on(
x.cur_code_from = 'EUR' -- Your- default currency here
and x.cur_code_to = 'SEK' -- The customers currency here
and o.order_close_date between x.valid_from and x.valid_to
)
where o.order_id = 1234;
- 每次比使用子查询更新。
然后,要转换为客户货币,您将加入此表:
order_close_date
此处我使用了{{1}}时有效的费率。因此,如果您有两个订单,一个关闭日期为2014-02-01,那么它将获得与截止日期为2014-04-05的订单不同的订单。
答案 1 :(得分:0)
我认为您只需在订单表中添加exchange_rate_id
并创建一个包含Exchange_Rates
,ex_rate_id
,description
列的查找表deleted
, created_date
。
因此,当订单关闭时,您只需更新带有id的订单表中的exchange_rate_id
列,稍后您可以使用查找表创建连接以提取记录。
请记住
这是一对多的关系,所以我不认为你必须为此制作一个单独的表格。如果你这样做,我认为会考虑额外的标准化。