不标识表中的id。

不标识表中的id是指在数据库中的表中，不使用自增长的id字段来标识每一条记录的唯一性。这种设计方式可以在一些特定场景下提供更好的性能和灵活性。

在传统的关系型数据库中，通常会使用一个自增长的id字段作为主键来标识每一条记录。这样做的好处是可以保证每条记录的唯一性，并且方便进行数据的增删改查操作。但是在某些情况下，使用自增长id字段可能会带来一些问题。

首先，自增长id字段会占用额外的存储空间。对于大规模的数据表来说，这个额外的存储开销是非常可观的。

其次，使用自增长id字段可能会导致数据的分布不均匀。因为新插入的数据通常会被分配到最后的id值，这样就可能导致数据在物理存储上的不均匀分布，从而影响查询性能。

另外，使用自增长id字段还可能引发一些并发性问题。在高并发的情况下，多个线程同时插入数据时，可能会出现id冲突的情况，需要额外的处理机制来解决。

不标识表中的id可以通过其他字段来保证记录的唯一性。例如，可以使用组合字段作为主键，或者使用全局唯一标识符（GUID）来代替自增长id字段。这样可以避免上述问题，并且在某些场景下可以提供更好的性能和灵活性。

总结起来，不标识表中的id是一种在数据库设计中不使用自增长id字段来标识每一条记录的唯一性的方式。它可以减少存储开销、避免数据分布不均匀和并发性问题，并在某些场景下提供更好的性能和灵活性。

腾讯云相关产品和产品介绍链接地址：

腾讯云数据库 MySQL：https://cloud.tencent.com/product/cdb_mysql
腾讯云数据库 PostgreSQL：https://cloud.tencent.com/product/cdb_postgresql
腾讯云数据库 MongoDB：https://cloud.tencent.com/product/cdb_mongodb
腾讯云数据库 Redis：https://cloud.tencent.com/product/cdb_redis

相关·内容

浅谈数据库设计技巧(下)（转）

三、多用户及其权限管理的设计　　开发数据库管理类的软件，不可能不考虑多用户和用户权限设置的问题。尽管目前市面上的大、中型的后台数据库系统软件都提供了多用户，以及细至某个数据库内某张表的权限设置的功能，我个人建议：一套成熟的数据库管理软件，还是应该自行设计用户管理这块功能，原因有二：　　1.那些大、中型后台数据库系统软件所提供的多用户及其权限设置都是针对数据库的共有属性，并不一定能完全满足某些特例的需求；　　2.不要过多的依赖后台数据库系统软件的某些特殊功能，多种大、中型后台数据库系统软件之间并不完全兼容。否则一旦日后需要转换数据库平台或后台数据库系统软件版本升级，之前的架构设计很可能无法重用。　　下面看看如何自行设计一套比较灵活的多用户管理模块，即该数据库管理软件的系统管理员可以自行添加新用户，修改已有用户的权限，删除已有用户。首先，分析用户需求，列出该数据库管理软件所有需要实现的功能；然后，根据一定的联系对这些功能进行分类，即把某类用户需使用的功能归为一类；最后开始建表：　　功能表(Function_table) 名称　　　　　类型　　　　约束条件　　　说明 f_id int 　无重复　　功能标识，主键 f_name char(20) 不允许为空功能名称，不允许重复 f_desc char(50) 允许为空功能描述用户组表(User_group) 名称　　　　　类型　　　　约束条件　　　说明 group_id int 无重复用户组标识，主键 group_name char(20) 不允许为空用户组名称 group_power char(100) 不允许为空用户组权限表，内容为功能表f_id的集合用户表(User_table) 名称　　　　　类型　　　　约束条件　　　说明 user_id int 无重复用户标识，主键 user_name char(20) 无重复用户名 user_pwd char(20) 不允许为空用户密码 user_type int 不允许为空所属用户组标识，和User_group.group_id关联　　采用这种用户组的架构设计，当需要添加新用户时，只需指定新用户所属的用户组；当以后系统需要添加新功能或对旧有功能权限进行修改时，只用操作功能表和用户组表的记录，原有用户的功能即可相应随之变化。当然，这种架构设计把数据库管理软件的功能判定移到了前台，使得前台开发相对复杂一些。但是，当用户数较大(10人以上)，或日后软件升级的概率较大时，这个代价是值得的。　　四、简洁的批量m:n设计　　碰到m:n的关系，一般都是建立3个表，m一个，n一个，m:n一个。但是，m:n有时会遇到批量处理的情况，例如到图书馆借书，一般都是允许用户同时借阅n本书，如果要求按批查询借阅记录，即列出某个用户某次借阅的所有书籍，该如何设计呢？让我们建好必须的3个表先：书籍表(Book_table) 名称　　　　　类型　　　　约束条件　　　说明 book_id int 无重复书籍标识，主键 book_no char(20) 无重复书籍编号 book_name char(100) 不允许为空书籍名称 …… 借阅用户表(Renter_table) 名称　　　　　类型　　　　约束条件　　　说明 renter_id int 无重复用户标识，主键 renter_name char(20) 不允许为空用户姓名 …… 借阅记录表(Rent_log) 名称　　　　　类型　　　　约束条件　　　说明 rent_id int 无重复借阅记录标识，主键 r_id int 不允许为空用户标识，和Renter_table.renter_id关联 b_id int 不允许为空书籍标识，和Book_table.book_id关联 rent_date datetime 不允许为空借阅时间 …… 　　为了实现按批查询借阅记录，我们可以再建一个表来保存批量借阅的信息，例如：批量借阅表(Batch_rent) 名称　　　　　类型　　　　约束条件　　　说明 batch_id int 无重复批量借阅标识，主键 batch_no int 不允许为空批量借阅编号，同一批借阅的batch_no相同 rent_id int 不允许为空借阅记录标识，和Rent_log.rent_id关联 batch_date datetime 不允许为空批量借阅时间　　这样的设计好吗？我们来看看为了列出某个用户某次借阅的所有书籍，需要如何查询？首先检索批量借阅表(Batch_rent)，把符合条件的的所有记录的rent_id字段的数据保存起来，再用这些数据作为查询条件带入到借阅记录表(Rent_log)中去查询。那么，有没有什么办法改进呢？下面给出一种简洁的批量设计方案，不需添加新表，只需修

转一篇他人写的数据库设计技巧，感觉也不一定都正确，开拓一下思路吧。说到数据库，我认为不能不先谈数据结构。1996年，在我初入大学学习计算机编程时，当时的老师就告诉我们说：计算机程序＝数据结构＋算法。尽管现在的程序开发已由面向过程为主逐步过渡到面向对象为主，但我还是深深赞同8年前老师的告诉我们的公式：计算机程序＝数据结构＋算法。面向对象的程序开发，要做的第一件事就是，先分析整个程序中需处理的数据，从中提取出抽象模板，以这个抽象模板设计类，再在其中逐步添加处理其数据的函数(即算法)，最后，再给类中的数据成员和函数划分访问权限，从而实现封装。　　数据库的最初雏形据说源自美国一个奶牛场的记账薄(纸质的，由此可见，数据库并不一定是存储在电脑里的数据^_^)，里面记录的是该奶牛场的收支账目，程序员在将其整理、录入到电脑中时从中受到启发。当按照规定好的数据结构所采集到的数据量大到一定程度后，出于程序执行效率的考虑，程序员将其中的检索、更新维护等功能分离出来，做成单独调用的模块，这个模块后来就慢慢发展、演变成现在我们所接触到的数据库管理系统(DBMS)——程序开发中的一个重要分支。　　下面进入正题，首先按我个人所接触过的程序给数据库设计人员的功底分一下类：　　１、没有系统学习过数据结构的程序员。这类程序员的作品往往只是他们的即兴玩具，他们往往习惯只设计有限的几个表，实现某类功能的数据全部塞在一个表中，各表之间几乎毫无关联。网上不少的免费管理软件都是这样的东西，当程序功能有限，数据量不多的时候，其程序运行起来没有什么问题，但是如果用其管理比较重要的数据，风险性非常大。　　２、系统学习过数据结构，但是还没有开发过对程序效率要求比较高的管理软件的程序员。这类人多半刚从学校毕业不久，他们在设计数据库表结构时，严格按照教科书上的规定，死扣E-R图和3NF(别灰心，所有的数据库设计高手都是从这一步开始的)。他们的作品，对于一般的access型轻量级的管理软件，已经够用。但是一旦该系统需要添加新功能，原有的数据库表差不多得进行大换血。　　３、第二类程序员，在经历过数次程序效率的提升，以及功能升级的折腾后，终于升级成为数据库设计的老鸟，第一类程序员眼中的高人。这类程序员可以胜任二十个表以上的中型商业数据管理系统的开发工作。他们知道该在什么样的情况下保留一定的冗余数据来提高程序效率，而且其设计的数据库可拓展性较好，当用户需要添加新功能时，原有数据库表只需做少量修改即可。　　４、在经历过上十个类似数据库管理软件的重复设计后，第三类程序员中坚持下来没有转行，而是希望从中找出“偷懒”窍门的有心人会慢慢觉悟，从而完成量变到质变的转换。他们所设计的数据库表结构有一定的远见，能够预测到未来功能升级所需要的数据，从而预先留下伏笔。这类程序员目前大多晋级成数据挖掘方面的高级软件开发人员。　　５、第三类程序员或第四类程序员，在对现有的各家数据库管理系统的原理和开发都有一定的钻研后，要么在其基础上进行二次开发，要么自行开发一套有自主版权的通用数据库管理系统。我个人正处于第三类的末期，所以下面所列出的一些设计技巧只适合第二类和部分第三类数据库设计人员。同时，由于我很少碰到有兴趣在这方面深钻下去的同行，所以文中难免出现错误和遗漏，在此先行声明，欢迎大家指正，不要藏私哦8) 　　一、树型关系的数据表　　不少程序员在进行数据库设计的时候都遇到过树型关系的数据，例如常见的类别表，即一个大类，下面有若干个子类，某些子类又有子类这样的情况。当类别不确定，用户希望可以在任意类别下添加新的子类，或者删除某个类别和其下的所有子类，而且预计以后其数量会逐步增长，此时我们就会考虑用一个数据表来保存这些数据。按照教科书上的教导，第二类程序员大概会设计出类似这样的数据表结构：类别表_1(Type_table_1) 名称　　　　　类型　　　　约束条件　　　说明 type_id 　 int 　无重复　　类别标识，主键 type_name　　 char(50) 不允许为空类型名称，不允许重复 type_father int 不允许为空该类别的父类别标识，如果是顶节点的话设定为某个唯一值　　这样的设计短小精悍，完全满足3NF，而且可以满足用户的所有要求。是不是这样就行呢？答案是NO！Why？　　我们来估计一下用户希望如何罗列出这个表的数据的。对用户而言，他当然期望按他所设定的层次关系一次罗列出所有的类别，例如这样：总类别　　类别1 　　　　类别1.1 　　　　　　类别1.1.1 　　　　类别1.2 　　类别2 　　　　类别2.1 　　类别3 　　　　类别3.1 　　　　类别3.2 　　…… 　　看看为了实现这样的列表显示(树的先序遍历)，要对上面的表进行多少次检索？注

--===================================================== --@@identity , SCOPE_IDENTITY,IDENT_CURRENT 三者的异同 --===================================================== --1.@@IDENTITY: 返回最后插入的标识值 IF OBJECT_ID('dbo.ta') IS NOT NULL DROP TABLE dbo.ta; CREATE TABLE dbo.ta ( ID INT IDENTITY PRIMARY KEY , Col VARCHAR(5) ); INSERT INTO ta SELECT 'A' INSERT INTO ta SELECT 'B' INSERT INTO ta SELECT 'C' SELECT @@IDENTITY AS Iden --Result : Iden -------------- 3 IF OBJECT_ID('dbo.tb') IS NOT NULL DROP TABLE dbo.tb; CREATE TABLE dbo.tb ( tb_id INT IDENTITY PRIMARY KEY , tb_col VARCHAR(5) ); --当触发器存在时, 返回被触发的表Identity列的值,不考虑任何作用域 IF OBJECT_ID('dbo.tr_ta') IS NOT NULL DROP TRIGGER dbo.tr_ta GO CREATE TRIGGER tr_ta ON dbo.ta FOR INSERT AS BEGIN INSERT INTO tb SELECT 'AA' END INSERT INTO ta SELECT 'D' INSERT INTO ta SELECT 'E' SELECT @@IDENTITY AS Iden --返回tb表中Identity列的值为2 --Result : Iden -------- 2 --2.SCOPE_IDENTITY:返回当前作用域中的标识列内的最后一个标识值 INSERT INTO ta SELECT 'F' SELECT @@IDENTITY AS [Identity]; SELECT SCOPE_IDENTITY() AS [SCOPE_IDENTITY]; --Result:返回tb表中最后的Identity为3，当前作用域中最后的Identity为6，即表ta中最后的Identity为6 Identity --------- 3 (1 row(s) affected) SCOPE_IDENTITY ---------- 6 (1 row(s) affected) --3.IDEN_CURRENT 返回指定的表或视图生成的最后一个标识值 INSERT INTO dbo.ta SELECT 'G' SELECT @@IDENTITY AS [Identity]; SELECT SCOPE_IDENTITY() AS [SCOPE_IDENTITY]; SELECT IDENT_CURRENT('ta') AS [IDENT_CURRENT_ta]; SELECT IDENT_CURRENT('tb') AS [IDENT_CURRENT_tb]; --Result: Identity -------------- 4 (1 row(s) affected) SCOPE_IDENTITY -------------- 7 (1 row(s) affected) IDENT_CURRENT_ta -------------- 7 (1 row(s) affected) IDENT_CURRENT_tb -------------- 4 --打开新的一个会话，不执行任何插入，如下： SELECT @@IDENTITY AS [Identity]; SELECT SCOPE_IDENTITY() AS [SCOPE_IDENTITY]; SELECT IDENT_CURRENT('ta') AS [IDENT_CURRENT_ta]; SELECT IDENT_CURRENT('tb') AS [IDENT_CURRENT_tb]; --Result： Identity --------------------------------------- NULL (1 row(s

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

不标识表中的id。

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐