橡树叶级的的[数据库设计]问题

业务描述:
电子书的发行，是将电子书（PDF文档）上传到数据库，客户经过网上支付获取积分，然后选购电子书，生成订单，进行下载。

<供应商表>与<电子书信息表>有个联系就是<供应电子书文件表>
<供应商表>( 供应商ID(主)，名称，合作状态，.... )
<电子书信息表>( 电子书ID(主)，书名，单价，货架状态，... )
<供应关系表>( 供应ID(主)，供应商ID(外)，电子书ID(外)，供应状态，电子书文件，供应时间 )
订单数据分为<订单表>和<订单细目表>,他们是一对多的包含关系。
  注：在<供应关系表>中新加了一主键"供应ID"，主要是为了在Hibernate中使用方便，"供应商ID"和"电子书ID"原本是复合主键。
      电子书文件是上传到数据库中的blob类型的文件。

1、电子书如何处理去留问题？
    在供应商终止合作的时候，先将<供应关系表>中的有关该供应商的记录的"供应状态"设为true，再将表中的有关该供应商的blob文件移到另外一张表<断货登记表>，最后将表中的电子书文件字段设置为null，设置<供应商信息表>中"合作状态"设为false。供应商就可以从<断货登记表>中导出数据，撤出商业活动。(这只是我的设计思路,大家有没有好的建议?)

2、<订单细目表>该不该与<供应关系表>建立关系？
   要知道，客户购买之后，要下载电子书文件的，所以<订单细目表>要有一个外键与<供应电子书文件表>关联。但是感觉很别扭。一个是实体，一个是联系。<订单细目表>、<电子书信息表>、<供应关系表>这三个表关系很乱。（大家帮我分析一下，谢谢了）

11 个解决方案

#1

#2

估计给钱都难搞.

#3

什么叫橡树叶级的解释一下。。

引用楼主 fzy777 的帖子:

2、 <订单细目表> 该不该与 <供应关系表> 建立关系？
要知道，客户购买之后，要下载电子书文件的，所以 <订单细目表> 要有一个外键与 <供应电子书文件表> 关联。但是感觉很别扭。一个是实体，一个是联系。 <订单细目表> 、 <电子书信息表> 、 <供应关系表> 这三个表关系很乱

是去<供应电子书文件表>查有没有对应记录(EBookID)?没有就提示没电子版有就下载么关于下载权限可能需要一张表维护的关于下载记录也可能需要一张表维护的

#4

[Suppliers]
supplierid name address pricontact bakcontact relationlevel validfrom validto...

[BookList]
bookid name pressname pubdate author shelfstatus stockquantity supplierid ...

[EbookList]
bookid ebooksize ebooklocation..

[Customers]
customerid customername address age profession level...

[OrderStatus]
orderid customerid bookid orderquantity actualprice discount occurdate cash/card ifcancelled deliverystatus

[Privilages]
Pid customerid bookid rights

[DownHistory]
Did customerid bookid downtime finalstatus...

#5

初步理解你的系统是用户访问你的网页输入用户名/密码之后浏览图书下订单下完订单之后可进行相应图书电子版本的下载同时选择快递/邮寄方式获取图书

Suppliers供应商表 validfrom显示该供应商承诺开始供应时间 validto可反映供应突然中断可再添加字段
BookList维护在售图书列表(非电子版)
EbookList记录有电子版图书文件的存在位置 (Path、Blog方式存储)
Customers注册会员信息列表
OrderStatus注册会员网上下订单记录如货到付款/网上支付是否取消是否送达等列信息
Privileges维护该会员可下载电子书信息
DownHistory记录会员已下载电子书信息

#6

没有非电子书，全部是电子书，没有配送方式什么的。订单有个有效状态字段，系统任务调度实现在规定时间进行更新这个字段，处于无效的订单，客户看不见，也无法下载了。所以不用下载历史什么的，因为有订单条目就应该够了吧？
谢谢大家答复，请再接再厉 :）

#7

那就更简单了

#8

什么呀

#9

等待牛人来答.

#10

不该建立联系

#11

关注

#1

#2