多对多（维护第三张表）重点（不能忘了set集合）

最新推荐文章于 2023-12-01 14:41:12 发布
最新推荐文章于 2023-12-01 14:41:12 发布
阅读量320 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： hibnate学习
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/lph2017/article/details/79258908
本文介绍如何通过简单的操作来实现用户角色的添加与移除，并强调了set集合在这些操作中的重要性。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

让某个用户具有某个角色

让某个用户没有某个角色   直接把第三张表  对应的记录  删除就可以了


 

set集合发挥了巨大作用   千万不要忽视



去掉某个角色



多对多第三张关系表
a584520584520584520的博客
06-11 2969
自定义多对多第三张关系表第三张多对多关系表中设置两个关联列另外两张表的外键 上图46，47行。再在内部写上一个Meta类 上图50行类里面写定义一个 unique_together = [('外键名1','外键名2')，] 这样就可以保证多对多联合唯一上图46，47行设置了unique=True 表示 每一条记录中该字段的值必须唯一 也就是一对一关系面试题 第23行 进行了切片处理 生成了一个新的...
MyBatis_多表查询的结果封装
qq_44509920的博客
07-25 5485
文章目录8.1. 多对一查询8.1.1. 确定查询需求8.1.2. 多对一环境8.1.3. 使用resultMap接收1. mapper接口方法2. 编写SQL片段3. 编写resultMap4. 测试总结8.1.4. 使用嵌套select查询1. 编写resultMap+嵌套select2. 编写statement3. 编写Mapper接口方法4. 测试总结8.1.5. 使用VO类接收1. 新增VO类2. 修改statement的resultType3. mapper接口方法4. 测试8.2. 一对多查询
三张表之间相互的多对多关系
weixin_30273931的博客
06-14 323
怎么办怎么办怎么办 转载于:https://www.cnblogs.com/losesea/archive/2012/06/14/2549564.html
多对多关系 通过第三张表体现出来
weixin_30488313的博客
01-20 269
转载于:https://www.cnblogs.com/classmethond/p/10294232.html
多对多关系中Set的查询
Done
01-05 187
多对多关系中Set的查询 一个老师教多个学生，一个学生有多个老师。class Teacher {String id;String name;Set students;}class Student {String id;String name;Set teachers;}现在要查询教某一个学生（name为xxx）的老师。HSQL方法一：（性能最优）select elements(s.teac...
关系型数据库 多对多(many to many)关系 三表还是两表
老专家的博客
01-24 1万+
关系型数据库 多对多关系 三表还是两表 ？多对多一般都是三张表，两张各自的单个信息表，一张表明关系的连接表。student//学生基本信息表 id name ... course//课程基本信息表 id name teacher... sc//选课表，每一条表明哪个学生选哪一门课， 可以只有两个字段 学生id或学号 课程id或课程号 表id有时候不是信息的id，如学号，
18-MySQL多表查询与事务的操作（数据库）
weixin_42688085的博客
12-23 905
感谢你的路过，希望学生的笔记能给你一点微不足道的参考 Java基础思维导图，完整Java体系的链接 一，多表查询 1.1多表查询的分类： 1.1.1内连接查询： 1. 隐式内连接：使用where条件消除无用数据 例子： -- 查询所有员工信息和对应的部门信息：SELECT * FROM em,dept WHERE em.dept_id = dept.id; -- 查询员工表的名称，性别。部门表的名称：SELECT em.name,em.gender,dept.name FROM em,de
深入理解Tair：阿里巴巴的分布式存储解决方案
热门推荐
张彦峰的博客
05-12 168万+
本文对Tair数据库进行了深入剖析，重点介绍了其架构设计、核心功能和应用场景。Tair作为阿里巴巴自主研发的分布式缓存系统，凭借高性能、灵活的存储模式以及强大的可扩展性，广泛应用于大规模分布式系统中。文章详细讲解了Tair如何实现数据高可用性、容灾恢复及多数据结构支持，同时分析了其在性能、可扩展性及一致性方面的优势与不足。最后，文章强调，尽管Tair具有诸多优点，但在复杂事务处理和特定场景下仍存在一定的优化空间，选择使用时需要根据具体需求权衡利弊。
ML学习分享系列3_计算广告小窥[下]要啥自行车！
寒小阳
08-22 2万+
提笔写这篇博客，我的内心是惶恐的。原因很简单，作为一个资历尚浅的研究生，是没有资格对计算广告这样一个伟大的行业、领域和学科来评头论足的。之所以这么做，一是总结自己已掌握的知识，二是降低同学们的学习成本。本人能力有限，更缺乏实践经验，文章内容多为书籍和论文的读后感，若有不当或者错误之处，还望各位同学指出，我定悉心求教。在此，向编写《计算广告》的刘鹏和王超两位老师致谢，向各位paper作者致谢。
实战进阶项目：《若依》码云知名开源项目·学习拓展笔记
心比天高，仗剑走天涯，保持热爱，奔赴向梦想！
11-26 5291
这里附上我的源码供大家学习（内含sql文件）： 链接利用若依开发商场销售程序 过程笔记-含源码前言一、商场销售程序是什么？二、使用步骤一.引入库二，修改配置三，新建模块四，代码生成五，拷贝生成文件六，controller层统一管理七，templates八 检查九，在admin中将goods模块引入。十，查看访问接口十一，建立目录十二，运行程序十三，新建模块，十四，生成菜单十五，创建角色十六，重写订单详情页面，1）模拟商场的扫码器，2）我们在页面就只用一个3）实现步骤：十七，提交按钮十八service层十九，
38 NESMA 维护多对多关系 案例
10-20 384
38 NESMA 维护多对多关系 案例
多表之间关系的维护（部分）
SHI_LUO_DE_YI_JI的博客
10-17 527
1.多表之间关系的维护 (1)外键约束：forerign key ①给product中的这个cno添加一个外键约束 1)alter table product add foreign key(cno) references category(cid);（references汉译：参考）（词句含义：product表中的cno和category中的cid对应：cno的1对应cid的1,cno的2对应cid的2） 2)从分类表中，删除分类为5信息， a.delete from category where cid
【MySql】多表
akiaug的日录
02-02 789
一、多表 多表简述 实际开发中，一个项目通常需要很多张表才能完成。 例如一个商城项目的数据库,需要有很多张表：用户表、分类表、商品表、订单表… 单表的缺点：冗余，同一个字段中出现大量的重复数据 相当于多表：把重复的数据封装成另一个表，数据看上去清晰明了，便于维护。 但是: 如果我们在从表的 连接主表字段 里面输入不存在的 值 ,数据依然可以添加 显然这是不合理的，所以我们要用到外键约束。 二、外键约束： 1. 什么是外键 外键指的是在从表中与主表的主键对应的那个字段,比如下图↓(员工表的 dept_
多对多第三张表的三种创建方式
weixin_34319111的博客
06-14 287
orm自动创建（可扩展性差，无法即时添加其他字段） class Book(models.Model): name = models.CharFiled(max_length=32) authors = models.ManyToManyField(to="Author") class Author(models.Model): name = models.CharFiel...
为什么需要三张表之多对多表结构设计
ylx_0716的博客
04-17 1176
了解完一对一和一对多表结构设计，接下来一起了解一下多对多的表结构设计。 同样，咱们先来想一般什么场景需要用到多对多。假如说咱们有一个叫订单和一个叫商品的这两张表，这两张表的关系，它其实就是一个多对多的关系。怎么理解？假如我双11产生了一个订单，这个订单里边有一本书，然后还有一个笔记本电脑，这就说明我这一个订单里边可以包含多个商品，另外，，不管是书还是笔记本电脑，它也有可能被其他的订单所购买？比如，...
_set的用法，本章适用多对多和一对多查询
Django_的博客
11-12 1548
说说set用法 首先你有两个类 一个类有桥（A） 一个正常(B) 1、如果通过A访问B 就是 A.桥.B中的属性 2、如果通过B访问A 就是 B_set.A中的属性 或者你在一对多或者多对多的外键中指定related_name的值 B.related_name.A中的属性 # Create your models here. class Yuedui(models.Model): ...
四、对于多对多关系的对象，如何建表
panchang199266的博客
06-17 6701
（一）背景介绍   在数据库中建表时，很容易遇到一种情况：一个学生选修了多门课，而每门课有多名学生选修，“学生”和“课程”之间就是典型的多对多关系。 （二）如何建表   遇到这种多对多关系，我们一般是创建三张表：Student（学生表）、Course（课程表）和选课表（id、student_id、course_id）...
模型层——多表操作
m0_71115526的博客
12-01 1012
实例：我们来假定下面这些概念，字段和关系作者模型：一个作者有姓名和年龄。作者详细模型：把作者的详情放到详情表，包含生日，手机号，家庭住址等信息。作者详情模型和作者模型之间是一对一的关系（one-to-one）出版商模型：出版商有名称，所在城市以及email。书籍模型： 书籍有书名和出版日期，一本书可能会有多个作者，一个作者也可以写多本书，所以作者和书籍的关系就是多对多的关联关系(many-to-many);一本书只应该由一个出版商出版，所以出版商和书籍是一对多关联关系(one-to-many)。
多对多关联映射
ChambersC的博客
10-17 753
Hibernate多对多关联映射
一对多表必须要创建第三张表记录对应数据吗？不能在多的那张表多加一个字段记录前一张表的id吗
最新发布
03-12
<think>好的，我现在要回答用户的问题：“一对多表必须要创建第三张表记录对应数据吗？不能在多的那张表多加一个字段记录前一张表的id吗”。首先，我需要理解用户的问题核心是什么。用户似乎在问，在一对多的数据库表关系中，是否必须使用第三张表（也就是关联表）来记录关系，还是可以直接在“多”的那张表里添加一个字段来存储“一”那边的主键ID。 首先，我应该回顾一下数据库设计中一对多关系的基本概念。一对多关系是指一个实体（比如部门）可以关联到多个另一个实体（比如员工），而每个员工只能属于一个部门。传统上，这种关系通常是在“多”的那张表（员工表）中添加一个外键字段（比如department_id），指向“一”那边的主键（部门表的id）。这样，不需要第三张表，直接在员工表中通过外键维护关系。 那用户为什么会提到“必须创建第三张表”呢？可能用户在某些资料或场景中看到使用第三张表的情况，感到困惑。这时候我需要考虑，第三张表通常用于多对多关系，而不是一对多。比如学生和课程的关系，一个学生可以选多门课，一门课可以有多个学生，这时候需要第三张表来记录选课情况。但在一对多关系中，通常不需要第三张表，直接在“多”方加外键即可。 所以用户可能混淆了一对多和多对多的处理方式，或者看到某些特定情况下使用第三张表的例子，误以为所有关系都需要第三张表。我的回答需要澄清这一点，说明在标准的一对多关系中，确实不需要第三张表，正确的做法是在“多”方添加外键字段。同时，可能需要解释为什么会有第三张表的误解，比如在某些框架或ORM中的特殊用法，或者设计上的其他考虑。 接下来，我需要确认是否有可能在一对多关系中使用第三张表的情况。例如，在某些情况下，如果关系本身有额外的属性（比如员工加入部门的时间），这时候可能需要一个中间表来存储这些额外信息，即使是一对多。但这种情况属于将关系升级为实体，属于特殊情况，并不常见。一般情况下，一对多不需要中间表。 因此，用户的问题的答案应该是否定的，即一对多不需要第三张表，直接在“多”方加外键即可。但需要详细解释清楚，避免混淆，同时指出可能存在例外情况，但大多数情况下不需要。 然后，我需要考虑用户可能存在的更深层次的疑问。比如，是否在某些ORM框架中，如Hibernate，会有不同的映射方式，导致用户产生困惑。或者用户可能看到某些数据库设计使用了中间表，误以为是一对多必须的。这时候需要举例说明标准做法和可能的例外情况。 另外，用户可能担心外键的性能问题，或者是否会影响查询效率。需要简要说明外键的优缺点，比如外键可以保证数据完整性，但可能在大量数据时影响性能，但这与是否使用中间表无关，而是外键本身的特性。 总结回答的结构应该是： 1. 明确回答：不需要第三张表，正确方法是在“多”方加外键。 2. 解释标准的一对多关系设计。 3. 对比多对多关系为何需要中间表。 4. 澄清用户可能的误解来源。 5. 举例说明正确做法。 6. 提及可能的例外情况（如关系带有属性）。 7. 总结外键的作用和注意事项。 同时，需要确保语言简洁明了，使用用户能理解的术语，避免过于技术化的表达，但又要准确无误。可能需要使用例子，比如部门和员工，订单和订单项等常见的一对多关系例子，帮助用户理解。 最后，检查是否有遗漏点，比如是否应该提到外键约束、索引优化等，但这些可能超出用户当前的问题范围，可以简要提及，但主要聚焦在是否需要用中间表的问题上。</think>### **问题解析** **不需要创建第三张表**。在一对多关系中，标准做法是直接在“多”的表（子表）中添加一个外键字段，指向“一”的表（父表）的主键。例如： - 父表：`部门表（department）`，主键为 `id` - 子表：`员工表（employee）`，添加外键字段 `department_id`，关联到 `department.id` --- ### **为什么不需要第三张表？** 1. **设计原则** - **外键直接关联**：通过在子表中添加外键字段（如 `department_id`），即可明确表示“一个部门对应多个员工”的关系。 - **数据冗余低**：子表直接存储父表的主键，无需额外表存储关联关系。 2. **对比多对多关系** 多对多关系（如“学生-课程”）需要第三张表（如 `选课表`），因为一个学生可以选多门课，一门课可以被多个学生选。而一对多关系中，子表的外键已经足够表示这种单向关联。 --- ### **标准实现示例** ```sql -- 父表（部门） CREATE TABLE department ( id INT PRIMARY KEY, name VARCHAR(50) ); -- 子表（员工） CREATE TABLE employee ( id INT PRIMARY KEY, name VARCHAR(50), department_id INT, -- 直接添加外键字段 FOREIGN KEY (department_id) REFERENCES department(id) ); ``` --- ### **常见误解场景** 1. **误将一对多设计为多对多** 若错误地认为“部门-员工”是多对多关系（例如允许一个员工属于多个部门），才会引入第三张表。此时需重新审视业务需求。 2. **框架或ORM的误导** 某些ORM工具（如Hibernate）在映射一对多时，可能默认生成中间表，但这通常是因为配置错误或框架限制，并非数据库设计的标准做法。 --- ### **需要第三张表的特殊情况** 仅当**关联关系本身需要额外属性**时，才考虑使用中间表。例如： - 记录“员工加入部门的时间” - 需要存储关联的附加信息（如角色、权重等） 此时中间表会包含： - 父表外键（`department_id`） - 子表外键（`employee_id`） - 附加字段（如 `join_date`） ```sql -- 中间表（部门-员工关系附加属性） CREATE TABLE department_employee ( department_id INT, employee_id INT, join_date DATE, PRIMARY KEY (department_id, employee_id), FOREIGN KEY (department_id) REFERENCES department(id), FOREIGN KEY (employee_id) REFERENCES employee(id) ); ``` --- ### **外键的优缺点** | **优点** | **缺点** | |-----------------------------|-----------------------------| | 保证数据完整性（如禁止删除有员工的部门） | 插入/更新时需检查外键约束，可能影响性能 | | 简化查询（直接通过 `JOIN` 关联） | 需要合理设计索引以优化查询效率 | --- ### **总结** - **标准做法**：一对多关系中，子表直接通过外键关联父表，无需中间表。 - **例外情况**：仅当关联关系需要额外属性时，才引入中间表。 - **设计建议**：优先使用外键，除非业务明确需要中间表的扩展性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值