sequence是什么意思（sequence中文意思）
引入这个概念，系统根据当前时间和机器码生成一个全球唯一的序列号。 与常用的传统 () 相比，它具有许多优点。
声称序列生成器只是简单地创建一个从给定起点开始的整数值序列，并且它用于在选择语句时自动递增序列。
生成的只能保证在单个内唯一，不适合在或者环境中作为 key使用，因为在各个环境中可能生成相同的，从而导致冲突。 将确保它创建的标识符在每个数据库中都是唯一的。
还有，序列必须是DML语句的一部分，所以它需要往返数据库（否则不能保证它的值是唯一的）。 这节省了不需要访问数据库的时间戳和机器标识符的查询开销。
当前示例：作者在设计公司的员工表时首先启用了它。 后来由于需要和传统系统对接（目前只识别类型字段），大改后改成。 在别人看来，1.的32位长度太长了，浪费存储空间。 2.不容易记住。 在做一些运维的时候，不如主键好记。 主键甚至可以起到漂亮数字的作用。
当然，在某些情况下，主键是一个字符串，由自定义函数生成，可以唯一标识，具有一定的业务意义。
主题讨论：
1、目前大家在工作中生成的主键是什么类型的，是什么原因？
2. 上述每种方法的优点或缺点是什么。
3、特殊情况下的主键生成（自定义方法），这是什么特殊场景，如何实现。
精彩回答：
东风酒哥：
1、目前大家在工作中生成的主键是什么类型的，是什么原因？
我目前使用，因为我尝试使用默认的东西
2. 上述每种方法的优点或缺点是什么。
:
优点：默认方式，简单易用
缺点：影响数据迁移，不支持分布式计算环境（多数据库会冲突）
:
优势：完美支持分布式计算环境，全球独一无二
缺点：生成时会消耗大量资源
自定义主键：
优点：可以根据需求实现任意格式的主键
缺点：需要自己写代码或者调用第三方库函数生成，生成效率低，不能保证唯一性
3、特殊情况下的主键生成（自定义方法），这是什么特殊场景，如何实现。
如果我要自定义主键，我会使用模块名+时间戳来生成
:
1、目前大家在工作中生成的主键是什么类型的，是什么原因？
好久没用了。 我记得至少八九年前我用过它。 后来使用了MySQL、SQL等数据库，也对各种数据库做了简单的比较。 数据库从8，8i一直用到11g。 我记得SQL数据库也支持GUID，但是我基本不用。 在原有的社保系统中，主键使用了一个序列，对于每个表序列都有特定的意义。 后来在SQL中，因为主键也有特定的含义，所以使用自定义的规则来生成主键。 不使用 GUID 的主要原因是因为我们系统中的主键是十位数字。 如果使用GUID，会造成存储空间的浪费。 由于我们的系统不是全球系统，因此不使用 GUID。
2. 上述每种方法的优点或缺点是什么。
：可以根据自己的要求定义具体的规则，让有一定的意义。 例如，在原有的社保系统中，收费表以“Start”开头，分配表可以用“Start”定义。 以头位区分。 也可以直接从0或1开始排序。SQL从2005年左右开始就支持序列了。序列也有它的缺点，因为序列是不断累积的，所以总有跑完天的可能。 如果不能在前期进行足够的预约，那么系统的使用寿命就无法....
GUID：由于 GUID 是全局唯一的，因此它作为分布式数据库系统中的主键特别有用。 或者用于全局软件系统。 但是对于本地使用的数据库系统来说，会造成存储的浪费。 在像这样的 ORM 框架中，最好使用 GUID 来标记唯一记录。
自定义主键：自定义主键可以根据自己的规则定义自己想要的主键，使其含义明确。 它比像 GUID 这样无意义的字符串更容易理解。 但是规则很繁琐，可能需要使用程序来维护构建。
3、特殊情况下的主键生成（自定义方法），这是什么特殊场景，如何实现。
特殊情况下的自定义主键必须有特殊的要求和含义。 例如在DICOM中，对每个实体的主键UID都有特殊的要求。 各个厂商在DICOM官方要求的字符串之后附加了自己的标识字符串，这样各个厂商在看到UID的时候就很容易区分了。 由自己的产品生成的文件和内容。 例如，每个公司都管理自己的文件编号，他们会按照一定的规则进行编号。 这些情况适合使用自定义主键。
:
1、目前大家在工作中生成的主键是什么类型的，是什么原因？ 通常考虑区分过期数据和有效数据，避免数据库管理中的一些问题，使用唯一的序列号作为系统中的主键，而不是某个字段名。 主要原因是在实践中，当业务实体属性的某个字段作为主键时，一开始分析大家认为没有问题，但是在后续的开发和维护中，往往会发现特殊情况下会出现数据更新等问题，所以还是希望能生成一个唯一编码的序列号作为主键来万无一失。
2. 上述每种方法的优点或缺点是什么。
这要视情况而定。 如果企业内部数据接口较多，核心应用系统交互频繁，那么推荐使用。 一般比较封闭的系统，传统的()。 原因很简单。 核心业务系统不太擅长更换数据库系统，通常也没有专门的时间做更换操作，只要后续版本升级兼容即可。 相反，对于一般的非关键业务，完全可以用开源数据库或者其他厂商的数据库来代替。 不管是什么数据库，都可以自定义生成一个传统的()。
3、特殊情况下的主键生成（自定义方法），这是什么特殊场景，如何实现。
这种特殊的场景并不是来自于数据库本身，而是客户业务处理中的一些异常。 例如，有时客户不需要在系统参数配置或业务管理中生成数据，需要在后台手动增删改查。 数据。 这种情况下，让系统按照规则生成一个唯一的主键是可行的，但是如果后台操作人员手动编译一个，完全有可能出错。
:
1、目前大家在工作中生成的主键是什么类型的，是什么原因？
目前基本都是使用生成唯一键的方式，但是还是要看平台，因为我们主要是做项目的。 如果是区域性项目，只有一个平台，那就是用的方法。 这种方法基本上是一般通用的模型，但是后来情况发生了变化。 有些项目由多层平台组成，下层的业务数据必须向上层上传。 这个时候我们使用了2个方法：
第一种：ID列采用type，前端业务通过自定义规则自动生成
第二个：通过guid生成
2. 上述每种方法的优点或缺点是什么？
优点：定义简单——1或0可以自定义为特殊的业务含义：关注节点、关注记录等。
缺点：上下级数据冲突会影响并发性能。 如果频繁插入数据，没有设置缓存，就会产生SQ-wait。
guid优点：guid保证全局唯一性，避免数据冲突
缺点：看不到业务意义，排查调试很麻烦
3. 特殊情况下的主键生成（自定义方法），这是什么特殊场景，是如何实现的？
对于全国性的平台，需要传输数据。 有上下层级联的平台环境，需要传输数据实现：使用平台码+时间戳+4位随机码看具体业务。 尽量保证唯一性，同时包含业务意义。 最早的时候不知道，有时候，用另一种方法生成唯一键，统一管理所有表，就是创建一个表，保存每个表的最大ID。 .
表名最大值
100
209
利用数据库的行锁原理，先将需要的表的一行更新为新的id，读出，释放锁，实现并发。
:
我给你一些水。 先引用一句：
引入了这个概念，它比管理员使用的传统 () 有很多优点。 序列生成器简单地创建一个从给定起点开始的整数值序列，它用于在选择语句时自动递增序列。 生成的只能保证在单个内唯一，不适合在或者环境中作为 key使用，因为在各个环境中可能生成相同的，从而导致冲突。 将确保它创建的标识符在每个数据库中都是唯一的。 另外，序列必须是DML语句的一部分，所以它需要往返数据库（否则不能保证它的值是唯一的）。从不需要访问数据库的时间戳和机器标识符中派生，这节省了查询开销
1、目前大家在工作中生成的主键是什么类型的，是什么原因？
大部分都用到了，guid也用到了。 我在之前做的一个项目中同时使用了两种方法。
1）更直观，符合设计习惯。 它还具有缓存，在一定程度上提高了性能。 2）guid乍一看是一串乱码，通常很恶心，但是有时候使用guid往往会有意想不到的效果，比如：对象在不同机器的不同数据库中生成，后面需要合并在一起的时候很有用. 因为这样可以防止主键冲突
2. 上述每种方法的优点或缺点是什么。
：优点——更直观，更易用，具有cache缓存顺序的效果
缺点--举个例子，像我们的系统迁移，如果以数据库的形式进行迁移，那么需要后台用脚本刷新序列，否则用户在使用系统时会出现异常，并且不支持分布式计算环境（多数据库会冲突）
guid：优点——支持分布式计算环境，全局唯一，之前设计的项目，记账系统经常发生代码变更，所以设计时直接生成全局唯一的代码作为关联主键，后续有等业务变更codes ，然后直接修改code，和其他系统对接时直接关联全局唯一code。 我个人认为这种方法比序列要好得多。
目前我们的报表系统设计，后台有很多关联主键是关联检索的guid。
缺点 - 需要根据应用场景选择合适的。 还有一个，GUID确实很耗空间，而且生成的代价比较大。 从目前的使用来看，()比较复杂； 作为主键，表和索引的存储成本更高； 索引查询慢于
自定义主键：优点——可以根据需要实现任意格式的主键
缺点——得自己开发代码，谁跟这玩意没关系。效率不好，效率比
3、特殊情况下的主键生成（自定义方法），这是什么特殊场景，如何实现。
以前在一个数据仓库中使用了两种自定义序列，一种是这样的； 另一种是用字母做序列，但是当用26个字母做序列时，要考虑字母用完时序列循环链的情况。 什么情况下用的，有点早就忘记了。
郑重声明：本文版权归原作者所有，转载文章仅出于传播更多信息之目的。 如作者信息标注有误，请第一时间联系我们修改或删除，谢谢。
