分布式项目不用外键的原因

最新推荐文章于 2024-12-01 18:46:33 发布
最新推荐文章于 2024-12-01 18:46:33 发布
阅读量700 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 数据结构
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/Asuna01/article/details/112229969

1.性能影响
大型互联网项目或者分布式项目，进行更新操作时，会在影响数据库性能
2.热更新
如果数据库存在外键，会导致新更新上去的代码无法运行，可能产生冲突，需要重新启动项目
3.降低耦合度
删除外键是指物理上删除外键，但是逻辑上还是存在外键的，这样就降低了表与表之间的耦合度（举个例子：用户表与用户订单表，用户订单表是有user_id字段，要查询用户订单，要通过user_id，这个user_id字段还是存在的）
4. 数据库分库分表
导致分库分表难以实现，举个例子，用户表和订单表有个外键关联，做分库操作，却有外键关联，就难以实现分库

数据库架构设计——分布式数据库设计
庄小焱
01-16 1万+
不用担心分片数量太多，因为分片 1 个还是 1000 个，管理方式都是一样的，但是 1000 个，意味着可以扩容到 1000 个实例上，对于一般业务来说，1000 个实例足够满足业务的需求了（BTW，网传阿里某核心业务的分布式数据库分片数量为 10000个）。但是表stock是库存品，是商品维度的数据，没有用户ID的信息。更重要的是，分布式数据库中的表，要能选出一个统一的分片键，即大部分表都能根据这个分片键打散数据，这样当后续业务进行访问数据时，可以在一个分片中完成单元化的闭环操作，不用涉及跨分片的访问。
OpenHarmony分布式数据库一致性解决方案【代码实战解决方案】
一键难忘的博客
08-09 3354
1.分布式共识算法为了实现分布式系统中的数据一致性，我们选用Raft算法作为核心共识机制。Raft算法通过选举领导者（主节点）来负责处理客户端的请求，并保证所有节点的日志（即数据操作记录）保持一致。2.自主主节点选取在OpenHarmony分布式网络中，每个设备根据自身的优先级（如设备级别、数据量等）进行主节点选举。我们设计了一个加权选举机制，设备级别和数据量作为权重因子，通过计算每个设备的加权值来确定主节点。3.数据实时同步。
AppBoxFuture(七): 分布式外键约束
weixin_30466953的博客
05-22 137
  关系数据库与NoSql其中的一个主要区别是具备完整的外键约束，虽说现在一些大厂在设计数据存储结构时禁止使用外键约束，靠业务逻辑来保证数据完整性，但考虑到是人就会犯错，为了保证关键业务数据的完整性，所以作者还是决定在存储引擎层面实现外键约束功能。 一、实现思路   由于存储引擎是分布式的，所以引用者与被引用者可能存在不同的节点上（如订单数据在节点1上，订单引用的产品数据在节点2上），这样实现外键...
为什么大多数项目的数据库都取消外键了（外键取消原因）
白小纯的博客
05-26 2662
数据库外键 如果一个字段a在一张表（表一）中是主关键字，而在另外一张表（表二）中不是主关键字，则字段a称为表二的外键； 主键表和外键表的理解 （1）以公共关键字（也就是两张表共有的字段）作主键的表为主键表（父表，主表） （2）以公共关键字（也就是两张表共有的字段）作外键的表为外键表（从表，外表） 外键的作用 主键保证了数据的唯一性，外键保证了数据的完整性。 主键是能确定一条记录的唯一标识，比如，一条记录包括身份正号，姓名，年龄。身份证号是唯一能确定你这个人的，其他都可能有重复，所以，身份证号是主键
分布式高级数据库（怀念一下我得了及格的高级数据库）
long636的专栏
06-22 9229
高级数据库技术 （一）引言 数据库系统的发展起始于19世纪60年代，从IBM的层次模型IMS、网状模型、关系模型，发展到多数模型共存的（同构和异构及其混合的形式共存的现状）。尤其是三位在数据库领域获得图灵奖的得主，查尔斯.巴赫曼，埃德加.科德和詹姆斯.格雷三人所对于数据库发展的贡献。尤其是科德在1970年发表的“大型共享数据库的关系数据模型”奠定了关系型数据库的基础。随着科学技术的发展，各
什么是外键，外键的作用
热门推荐
Asuna01的博客
01-05 3万+
什么是外键： 如果一个实体的某个字段指向另一个实体的主键，就称为外键。被指向的实体，称之为主实体（主表），也叫父实体（父表）。负责指向的实体，称之为从实体（从表），也叫子实体（子表） 外键的作用： ①为了一张表记录的数据不要太过冗余。 ②保持数据的一致性、完整性。 是否有必要使用外键？ 正方（需要） 1.数据一致性 由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据 的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。 e
为啥不推荐使用数据库外键
qq_62097431的博客
12-01 635
在阿里开发手册中写道：不得使用外键与级联，一切外键概念必须在应用层解决。说明：（概念解释）学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度。适应分布式、高并发环境。
SpringBoot+MybatisPlus 分布式项目谷粒商城.zip
04-19
MySQL广泛应用于各种规模和类型的项目，包括但不限于： Web应用程序：作为众多网站和Web服务（如电子商务、社交媒体、内容管理系统等）的后台数据库。 数据分析与报表：与数据仓库技术结合，支持OLAP（在线分析...
分布式 PostgreSQL 集群(Citus)官方教程 - 迁移现有应用程序
m0_67788957的博客
03-17 741
目录 确定分布策略 选择分布键 确定表的类型 为迁移准备源表 添加分布键 回填新创建的列 准备申请 Citus 建立开发 Citus 集群 在键中包含分布列 向查询添加分布键 其他（SQL原则） 启用安全连接 检查跨节点流量 迁移生产数据 小型数据库迁移 大数据库迁移(Citus Cloud) 重复 schema 启用逻辑复制 ..
Django-Multitenant，分布式多租户数据库项目实战(Python/Django+Postgres+Citus)
o__cc的博客
03-19 991
Python/Django 支持分布式多租户数据库，如 Postgres+Citus。 通过将租户上下文添加到您的查询来实现轻松横向扩展，使数据库(例如 Citus)能够有效地将查询路由到正确的数据库节点。 构建多租户数据库的架构包括：为每个租户创建一个数据库、为每个租户创建一个 schema 和让所有租户共享同一个表。这个库基于第三种设计，即让所有租户共享同一个表，它假设所有租户相关的模型/...
05----------高并发下的数据库表或者大多数情况下，不再使用外键
冷炎嗄的博客
08-27 1312
在学校时，我们经常使用外键来关联表格，这样可以保证数据的一致性， 但实际上，在很多场景下，我们并不太需要保证数据的一致性，而是需要效率， 而且现在随着分布式的流行，很多情况下一个数据库已经不再适合使用，因此外键也就不再使用 例如:商品表goods public class Goods { private Long id; //商品ID private Stri...
分布式数据库之分布键
MyySophia的博客
04-01 1万+
Update报错： Cannot parallelize an UPDATE statement that updates the distribution column 1个或者数个table column被作为distribution key（DK） 。DK被Hash算法用来决定每行记录对应特定的segment instance。 相同的key值记录会Hash到相同的segme...
为什么数据库不应该使用外键
HollisChuang's Blog
06-16 1093
当我们想要持久化地存储数据时，使用关系型数据库往往都是最稳妥的选择，这不仅因为今天的关系型数据库种类非常丰富并且稳定，还因为不同社区对关系型数据库的支持都非常完备。我们在前面的文章中曾经...
一文一点 | 为什么不建议使用数据库外键
新栋BOOK
08-25 1199
你好，这是【一文一点】的第1篇文章，不拘泥于篇幅字数，用一篇文章说清一个知识点。有的SQL规约是这么说的：【强制】不得使用外键与级联，一切外键概念必须在应用层解决。那先复习下是什么...
数据库中为什么不推荐使用外键约束
斌斌的博客
09-26 562
引言 其实这个话题是老生常谈，很多人在工作中确实也不会使用外键。包括在阿里的JAVA规范中也有下面这一条 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。 但是呢，询问他们原因，大多是这么回答的 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦,测试数据极为不方便。 坦白说，这么说也是对的。但是呢，不够全面，所以开一文来详细说明。 正文 首先我们明确一点，外键约束是一种约束，这个约束的存在，会保证表间数据的关系“始终完整”。因此，外键约束的存在，并非全然没有优点
【原创】数据库中为什么不推荐使用外键约束
weixin_30312659的博客
11-05 3121
引言 其实这个话题是老生常谈，很多人在工作中确实也不会使用外键。包括在阿里的JAVA规范中也有下面这一条 【强制】不得使用外键与级联，一切外键概念必须在应用层解决。 但是呢，询问他们原因，大多是这么回答的 每次做DELETE 或者UPDATE都必须考虑外键约束，会导致开发的时候很痛苦,测试数据极为不方便。 坦白说，这么说也是对的。但是呢，不够全面，所以开一文来详细说明。 正文 首先我们明...
java项目的mysql设计会不会引入外键
最新发布
03-16
<think>嗯，用户问的是Java项目的MySQL设计会不会引入外键。首先，我需要理解外键在数据库设计中的作用和优缺点。外键主要用于维护数据的参照完整性，确保子表中的数据在父表中存在对应的记录。这对于防止数据不一致很有帮助。 然后，用户可能关心的是在Java项目中使用外键的实际考量。比如性能方面，外键约束可能会影响插入、更新和删除的速度，特别是在高并发的情况下，因为需要检查约束和可能锁定相关的表。此外，分库分表时，外键的支持可能有限，这也是需要考虑的。 另外，应用层处理外键逻辑也是一个选择。比如使用ORM框架如Hibernate，可以在应用层通过代码来维护数据一致性，这样可能更灵活，但需要开发者自己确保逻辑正确，避免脏数据。 还有微服务架构的问题，如果数据库分散在不同服务中，外键就无法跨库使用，这时候只能依赖应用层的校验。这也是为什么一些分布式系统会避免外键的原因。 还要考虑团队规范和开发习惯。有些团队可能更倾向于使用外键来依靠数据库自身维护完整性，而有些则希望减少数据库的依赖，方便水平扩展或迁移。 需要提醒用户根据具体场景权衡，比如数据一致性的重要性与性能需求的平衡。如果数据量不大，且需要强一致性，外键是个好选择。而对于高并发或分布式系统，可能更适合在应用层处理。</think>在Java项目的MySQL数据库设计中，是否引入外键需要根据具体场景权衡。以下是关键分析步骤： 一、外键的核心作用 $$ \text{Foreign Key} \rightarrow \text{保证数据参照完整性} $$ 通过约束关系表间的数据关联，自动维护父子表的一致性（级联更新/删除） 二、引入外键的优势 1. 强数据一致性：防止脏数据（如订单关联不存在的用户ID） 2. 简化开发：数据库自动处理关联约束，减少应用层校验代码 3. 可视化关联：数据库ER图清晰展示表关系 三、潜在问题与限制 1. 性能影响： - 写操作增加约束检查开销（约10-15%性能损耗） - 高并发场景可能引发锁竞争 $$ T_{operation} = T_{base} + T_{check} $$ 2. 分库分表障碍：分布式架构中难以实现跨节点外键 3. ORM框架适配：Hibernate/MyBatis等工具需要特殊处理级联操作 四、典型替代方案 1. 应用层校验（Java代码逻辑控制） ```java public void createOrder(Long userId) { if(!userRepository.existsById(userId)) { throw new InvalidUserException(); } // 创建订单逻辑 } ``` 2. 异步校验机制（最终一致性） 3. 逻辑删除兼容方案（使用is_deleted标记替代物理删除） 五、决策建议矩阵 | 场景特征 | 推荐方案 | 说明 | |-----------------------|--------------|-------------------------| | 强事务需求/单机部署 | 使用外键 | 保证即时一致性 | | 高并发写操作/分布式架构 | 应用层控制 | 避免锁争用和分库限制 | | 复杂业务逻辑/频繁结构变更 | 混合方案 | 关键核心表用外键，边缘关系应用层控制 | 实践建议：初期建议建立外键关系快速验证业务模型，在性能测试阶段根据实际压力决定是否保留。对已有系统改造，可通过数据库触发器+应用层校验实现平滑过渡。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值