Heim  >  Artikel  >  Backend-Entwicklung  >  在数据库中怎么做到所有用户共用一张表,但是每个用户的订单编号却是独立的命名空间?

在数据库中怎么做到所有用户共用一张表,但是每个用户的订单编号却是独立的命名空间?

WBOY
WBOYOriginal
2016-08-04 09:20:401240Durchsuche

1.实际场景:
数据库中订单表是公用的,所有用户在一张订单表上。
怎么让每个用户的订单编号是独立的命名空间?比如用户A下了两张订单,他的订单编号应该是C001、C002,用户B下了三张订单,他的编号起始位置应该还是C001,而不是C003,他的所有订单编号应该是C001,C002,C003。
请问怎么做到这一点?
难道要在每个用户底下存一个他当前开了多少个订单的字段,然后每次先读出来,加一,再存回去?这不太好吧……有没有更好的方法,在数据库端就做了?好像听人说起过用数据库函数或者触发器?

2.如果数据库能做到上述这一点,请问这个C001一般是存在主键字段里么?还是主键依然是一个数字类型的递增主键,只是在表中增加一个字段去存这个C001?

注:是在Mysql数据库中。

回复内容:

1.实际场景:
数据库中订单表是公用的,所有用户在一张订单表上。
怎么让每个用户的订单编号是独立的命名空间?比如用户A下了两张订单,他的订单编号应该是C001、C002,用户B下了三张订单,他的编号起始位置应该还是C001,而不是C003,他的所有订单编号应该是C001,C002,C003。
请问怎么做到这一点?
难道要在每个用户底下存一个他当前开了多少个订单的字段,然后每次先读出来,加一,再存回去?这不太好吧……有没有更好的方法,在数据库端就做了?好像听人说起过用数据库函数或者触发器?

2.如果数据库能做到上述这一点,请问这个C001一般是存在主键字段里么?还是主键依然是一个数字类型的递增主键,只是在表中增加一个字段去存这个C001?

注:是在Mysql数据库中。

1:数据库中不用那样存,你只需要遍历出来所有定单之后,显示时按顺序就行了。
2:给每个用户属性中增加静态成员变量,并且数据库中相应增加字段,每次加入的数据就是你说的样子了。

楼主的意思应该是建立不同客户账户的统一订单管理库,不同账户只能看到属于自己的订单,有点类似云erp。

订单表可以冗余一个主键id,在数据存储唯一性上面,可以看为订单code+用户id来唯一确认一条数据。

如果说需要表结构优化设计的话,可以根据每个用户自动建立一张订单表,将每个用户的订单数据独立出来,表名类似order_userid 每次根据用户找到对应表名取数据,但在最后的综合后台对所有用户订单数据统计可能会稍微麻烦些。

请问你如何保证订单的唯一

如果根据题述意思设计数据库,则仅查找订单这一操作就将出现异常。因为我们根据订单号无法确定唯一订单
主键的值用于唯一地标识表中的某一条记录。

(关于你的项目
我建议:
订单这张表的主键可以是OrderId
而用户表的主键可以是UserId
我认为您的问题应该出在数据库表的基本理解上。建议阅读数据库规范化的相关内容。)

  1. 用一个orderid表存放所有用户下一个order的id,如果觉得麻烦建议你用时间作为订单号的一部分。

  2. 不能作为主键,主键设计有一个原则——必须是和业务无关的。所以主键永远都是无意义的自增ID之类的。

我看不出你这个问题是要解决什么实际的需求

表结构的设计,要遵守最基本的三个范式的要求。三个范式的目的,是要保证字段之间不要有冗余,不要有依赖。上面几位说的问题,我就不重复了,你这样设计,违反了数据库表结构设计的三大范式的原则,建议你好好理清楚需求,不应该做这样的设计,或者我们理解错了,你把问题重新表述一番。或者直接贴出你的建表语句来。

可以使用联合主键将uid和cid组合起来,这就就可以保证唯一性了。但要注意如下两点:
1、要使用mysql联合主键自增,需使用MyISAM作为存储引擎。
2、使用联合 主键自增的时候,自增键不能是主键最左的键。

order表里面增加一个user_owner_order_key,然后自己写代码处理 C001 这种东西与真实order_id之间的互换逻辑就行了。

<code>//伪码 
$user_owner_order_id = (select count(*) from order where user = $uid and order_id </code>

说一个其他方面的问题,一般的第三方支付对于同一个订单号是无法多次付款的,所以最好考虑清楚要不要这样做。

解决方法


  1. 用户表可以有一个字段存放订单数量,每次有新订单就取这个值加一,然后更新回去;

  2. 新订单获取已有订单的条数,加一,不过这个删除订单的时候必须是软删除了

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn