数据表中订单id设计

ID的生成

在我们熟知的各种数据中，一般主键ID都是一个全局无重复的整数类型(long),比如数据库的主键id，是递增增长的，在订单中,订单id的生成就比较有讲究，需要兼顾效率和唯一性:

• 订单ID的要求：全局唯一性高性能:并发要高、延迟低、在一些大型公司,很重要高可用:稳定、不容易挂掉简单易用:

目前,在订单ID生成的选择上大致有如下几种方式选择：

1. 自增的id:一般对于要求不高，量级和并发都不大的情况下使用
2. 时间戳+随机数
3. 分布式算法UUID生成雪花算法等
4. 订单序号+其他信息（时间、日期、序号、...）例如淘宝id号：就是序号+买方信息等拼接而成

一般订单id是作为数据库主键存在，而订单号则并非数据库主键。

ID相关

了解ID的生成规则，将在数据研发或者模型设计中给我们带来一些额外的优势和方案的选择。特别是计算一些指标的过程中，了解不同id的生产方式，会带来一些突破计算瓶颈的意外收获。

比如用户id，订单id等，这里我们重点谈论订单id的部分，其它的id类似。

• 订单id生成-案例1：

订单id:一般以Long类型数据存在并且全局唯一。在用户下单过程中一般根据下单的事假戳拼接而成，如下为一种生成的逻辑。

• 订单id生成-案列2：

订单号的生成跟订单id生成类型，但是底层逻辑上有所不同：

需要注意：

1. 由于在存在技术升级和分布式ID的拼接存在：可能会导致一部分数据在拼接的时候，高N位存在差异。

例如：除了符号位，高32位中，不确定会存在多少空位，也就是后面拼接的id存在长短差异

数据中如何使用

知晓了订单ID的生成规则，就可以利用规则做很多数据模型层面的优化和信息整合

• 由于订单id是整形，则可以利用bitmap的方式对订单进行去重
• 由于订单中包含秒级别的完整时间，就可以不需要全局排序获取用户首末次订单的信息和对应的时间信息
• 可以利用订单id生成的方式，重新拼接信息，来进行更多信息的编码：例如，可以将时间+店铺+商品类型进行64位编码的重新组合，用高32位存储时间，中间20位存储店铺id，后12位存储商品大类，生成一个新的id来表示类似信

实际的案例：

1. sparksql中的例子：

1. UDF封装