ORDER ITEM
ORDER_ID(PK) ITEM_ID(pk)
| |
| |
| |
ORDER_ITEM——
ORDER_ID (PK)
ITEM_NUM (PK)
ITEM_ID(FK) 书上看到的,
ORDER_ITEM对ORDER标识依赖,对ITEM非标识依赖,删除ITEM不删除对应的ORDER_ITEM。
那如果删除一个ITEM,ORDER_ITEM的对应项怎么办?
设为NULL,那过去的ORDER(订单)对应项都得设为NULL,显然不行。
取消 外键依赖 那会影响以后的新ORDER_ITEM的插入。顺便问一下,数据库建模一般是DBA的事,还是架构师的事?
ORDER_ID(PK) ITEM_ID(pk)
| |
| |
| |
ORDER_ITEM——
ORDER_ID (PK)
ITEM_NUM (PK)
ITEM_ID(FK) 书上看到的,
ORDER_ITEM对ORDER标识依赖,对ITEM非标识依赖,删除ITEM不删除对应的ORDER_ITEM。
那如果删除一个ITEM,ORDER_ITEM的对应项怎么办?
设为NULL,那过去的ORDER(订单)对应项都得设为NULL,显然不行。
取消 外键依赖 那会影响以后的新ORDER_ITEM的插入。顺便问一下,数据库建模一般是DBA的事,还是架构师的事?
设为NULL,那过去的ORDER(订单)对应项都得设为NULL,显然不行。---------如果不行就关联删除,删除item order会被删除,要不就记录多余的数据,将item中的一部分数据在order再记录一份
数据库建模一般是DBA的事,还是架构师的事? --------个人觉得通知应该是架构师做的。
书上说把order和order_item间为标识依赖,order_item为弱实体,删除order(订单),order_item(订单项)就没存在的必要了。
删除相应的商品,对应的order_item(订单项)不删除(可能是为了可追溯,过去的订单不应更改,正在处理的订单标识为异常(这怎么实现,加一个备注项?)),
那就不能设为NULL,
关联删除也不行,
order和order_item为一对多,order_item和item为多对一,(将item中的一部分数据在order再记录一份,item和order_item为多对多啊,怎么记录?)
现实中的电子商务网站怎么处理的,禁止删除ITEM表中的项,那ITEM表不是越来越大,过久以前的商品也没记录的必要(虽然过久的订单有)。
书上说把order和order_item间为标识依赖,order_item为弱实体,删除order(订单),order_item(订单项)就没存在的必要了。
删除相应的商品,对应的order_item(订单项)不删除(可能是为了可追溯,过去的订单不应更改,正在处理的订单标识为异常(这怎么实现,加一个备注项?)),
那就不能设为NULL,
关联删除也不行,
order和order_item为一对多,order_item和item为多对一,(将item中的一部分数据在order再记录一份,item和order_item为多对多啊,怎么记录?)
现实中的电子商务网站怎么处理的,禁止删除ITEM表中的项,那ITEM表不是越来越大,过久以前的商品也没记录的必要(虽然过久的订单有)。
(将item中的一部分数据在order再记录一份,item和order_item为多对多啊,怎么记录?)
写错了,item和order为多对多
我觉得是开发人员和dba事情,如果这个架构师也管,太累!
不做数据库级别的主外键关联关系。怎么确定新增订单项中商品的有效性。每次插入的时候对取一次ITEM表?这影响效率吧。