关系型数据库设计

kyle960 发布于 2018/12/12 15:13
阅读 705
收藏 0

现在设计一个数据库,

表1:商品编号,商品名称,商品信息

表2:商店编号,商店名称,商店经度,商店纬度

表3:交易编号,商店编号,商品编号,商品数量

问题:

1.商店或商品信息变化,导致交易记录不准确。比如,一年前的一笔交易A,商品B按10元价格,在商店C成交。但一年后,商品B价格变成了5元,商店C也搬了位置。那么,交易A的记录显然就不正确了。如果把所有信息都存到交易表里面,数据是不是又重复得严重了。

2.如果商品B被下架,商店C被关闭了呢?数据还不能删除?

这两个问题要怎么解决呢?

加载中
0
DeMoNHaDeS
DeMoNHaDeS

通常,像交易记录、日志等等这种需要留档性质的数据,重要字段需要存储明细数据而不是只存一个关联id,否则,关联数据的变动都可能会引起历史记录信息变化。这样的设计并不违背3NF。

下架和关闭这种情况通常做逻辑删除而不是物理删除。

l
linux_lk
可以
k
kyle960
Thanks
0
自由PHP
自由PHP

这种情况最糟糕,一般是单独的订单表,去存储订单的详细信息,比如商品名称、规格、货号等,防止商品信息修改导致订单查询出现问题,避免交易纠纷,淘宝已经做到了什么地步,淘宝为每一次商品详情页的修改都做了一次快照,订单对应着商品的哪个快照都有记录,就和你的git一模一样,版本全存

订单和商品,你要看成两个独立的系统,这样你方便你后期做解耦,也不会出现你说的什么重复、冗余

另外,商品交易涉及金钱交易,数据保存的越详细越好。

k
kyle960
对哦,类似版本控制。 表1:版本id,商品编号,商品信息 表2:商品编号,版本id 表1只增加记录,不修改记录。 修改商品信息就在表1插入一条记录,同时更新表2的版本id。 交易信息表,记录版本id,而不是商品编号。
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部
返回顶部
顶部