问一个数据库设计的问题

哎码 发布于 2016/10/17 17:50
阅读 523
收藏 0

问一个数据库表设计的问题,自己想的有点乱。

业务是这样的:

物品经过推荐,到鉴定,然后出售。

物品有好多种类,每种字段差距很大,所以每种都是一张表,这个固定了。

现在就有这些表了:

recommend(推荐),evalute(鉴定),order(出售订单表),这几张表也固定了

每种物品可能经过推荐-鉴定-出售,那就是每张物品表都对应这三张表。问题是它们之间的关系应该怎么做?

如何做才能在开发中写SQL好写一点,并且逻辑通顺?

目前想的是三张中间表,每种对应一个环节(推荐/鉴定/出售),对物品种类做标记位;

还有一种想法是一张中间表,对物品种类和环节做标记位,但是这样估计SQL会很难写。

大家有做过类似的业务吗?

加载中
0
颓废的幻想者
颓废的幻想者
只能中间表了 设计的太烂了 这个结构
0
kakai
kakai
每种物品就是一张表,这种设计本来就有问题吧,应该把所有物品统一到一张表中去,有些人的做法是用列式数据库,可以动态扩充字段。
0
hzajie
hzajie

这类库表设计与你的业务直接相关,只有在吃透业务需求的基础上,才能很好地体现和设计业务,但有一个建议给你,不建议多表之间进行join类操作,否则等你记录量上去后,你会发现性能非常 痛苦.

0
谦虚的兔子

物品表中,加一个int类型的status字段, 其中1表示推荐 2-鉴定 3-出售

比如查询处于出售状态的物品:

select * from table where status = 3

0
jiannan
jiannan
recommend(推荐),evalute(鉴定),order(出售订单表)放到三张表里,不引用中间表的话,一个物品经过三个环节就出现了三行数据, 如果放到一张表里面的三个字段中,加一个物品id或编号列等,走到哪一步了就插入一个特定值,是不是只有一行数据,如果怕以后数据量大了那就不是表的问题了。
0
Joyzhou
Joyzhou
这种设计。。已经怎么扩展
0
求是科技
求是科技

两张表就够了嘛

物品表(物品id、物品信息、种类id、状态(推荐/鉴定/出售))、种类表(种类id、种类信息),这样设计也方便扩展,只要与物品相关的,可以单独设计表,也可以直接向物品表里面添加。备注:这种设计插入/查询方便,但是对单表的压力比较大,所以建议做读写分离。

0
哎码
哎码

亲们,每种物品是可以同时存在3种状态的,比如这种物品经过推荐到了鉴定,咱们不能把他从推荐中删除,最多状态是完成状态。

还有物品表不是我的活啊。。我没法改了。。。

554330833a
554330833a
那就要建中间表
Sel8616
Sel8616
这个你不用担心啊,你的3个步骤是顺序推进的。所以,状态为2时,必然经过了状态1。。。物品表你是没法改,提提建议还是可以的吧
0
qycms_cn
qycms_cn

"物品有好多种类,每种字段差距很大,所以每种都是一张表,这个固定了",

抽出通用的字段,如id,sort,name,price,status,created,updated, data(text,bigtext)

其它不同的,为每类产品起来对象,当需要存储时 object=>toJson,通通扔给data字段。

0
554330833a
554330833a
recommend(推荐),evalute(鉴定),order(出售订单表) 是流程,直接在物品表加一个字段就可以了啊,还建那么多表干嘛
返回顶部
顶部