4.引用外键的优缺点

作用:保持数据的一致性、完整性

 

为何说外键有性能问题:

1.数据库需要维护外键的内部管理;

2.外键等于把数据的一致性事务实现,全部交给数据库服务器完成

3.有了外键,当做一些涉及外键字段的增,删,更新操作之后,需要触发相关操作去检查,而不得不消耗资源

4.外键还会因为需要请求对其他表内部加锁而容易出现死锁情况

 

数据库外键的使用以及优缺点

摘录网上讨论共同观点:主键和索引是不可少的,不仅可以优化数据检索速度,开发人员还省不其它的工作,
矛盾焦点:数据库设计是否需要外键。这里有两个问题:一个是如何保证数据库数据的完整性和一致性;二是第一条对性能的影响。

正方观点: 1,由数据库自身保证数据一致性,完整性,更可靠,因为程序很难100%保证数据的完整性,而用外键即使在数据库服务器当机或者出现其他问题的时候,也能够最大限度的保证数据的一致性和完整性 eg:数据库和应用是一对多的关系,A应用会维护他那部分数据的完整性,系统一变大时,增加了B应用,A和B两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性,而且一年以后如果又增加了C应用呢? 2,有主外键的数据库设计可以增加ER图的可读性,这点在数据库设计时非常重要。 3外键在一定程度上说明的业务逻辑,会使设计周到具体全面。


反方观点: 1,可以用触发器或应用程序保证数据的完整性 2,过分强调或者说使用主键/外键会平添开发难度,导致表过多等问题 3不用外键时数据管理简单,操作方便,性能高(导入导出等操作,在insert,   update,  delete   数据的时候更快)eg:在海量的数据库中想都不要去想外键,试想,一个程序每天要insert数百万条记录,当存在外键约束的时候,每次要去扫描此记录是否合格,一般还不止一个字段有外键,这样扫描的数量是成级数的增长!我的一个程序入库在3个小时做完,如果加上外键,需要28个小时! 

 


结论: 1在大型系统中(性能要求不高,安全要求高),使用外键;在大型系统中(性能要求高,安全自己控制),不用外键小系统随便,最好用外键。 2,用外键要适当,不能过分追求 3,不用外键而用程序控制数据一致性和完整性时,应该写一层来保证,然后个个应用通过这个层来访问数据库。

 

### 物理与逻辑概述 #### 概念定义 物理是在数据库层面通过约束机制实现的一种参照完整性控制手段。这种由数据库管理系统(DBMS)强制执行,确保子表中的记录始终指向父表中存在的有效条目[^1]。 相比之下,逻辑并不依赖于数据库系统的内置功能来维护关联关系;而是依靠应用程序级别的编码逻辑,在应用层面上处理跨表之间的引用规则。这意味着开发者需自行编写代码以保证数据的一致性[^2]。 #### 优点分析 对于物理而言: - **增强的数据一致性**:由于其直接作用于底层存储结构之上,因此能够有效地防止违反参照完整性的操作发生。 - **简化编程工作量**:可以减少大量用于验证和同步多张表格间联系的应用程序代码。 - **自动化的级联操作支持**:允许设置删除或更新时的行为模式,如CASCADE, SET NULL等选项[^5]。 然而,采用逻辑方式管理也有特定的优势: - **灵活性更高**:不受限于具体RDBMS特性,可以在不同类型的数据库之间迁移而不必担心兼容性问题。 - **便于调整架构**:如果未来需要改变现有模型,则无需修改现有的SQL语句或其他基础设施组件即可轻松适应新的业务需求[^4]。 #### 缺点探讨 尽管物理提供了强大的保障措施,但也存在一些潜在的风险因素: - 可能引发性能瓶颈特别是在高并发场景下频繁访问涉及多个实体的对象时可能会造成显著延迟; - 容易引起死锁现象尤其是在复杂查询条件下当事务试图锁定同一资源的不同部分时更容易出现问题[^3]。 至于逻辑则面临如下挑战: - 需要额努力维持数据准确性这不仅增加了开发成本还可能引入人为错误的机会; - 对程序员技能提出了更高的要求即必须具备足够的经验才能正确无误地实施此类策略。 #### 实际开发中的选择考量 在决定是否使用物理还是逻辑钥之前应该综合评估以下几个方面: - **项目规模和技术栈**:小型项目或许更适合利用简单的硬链接方案快速搭建原型;而对于大型企业级解决方案来说,考虑到长期可维护性和扩展能力往往倾向于软连接的设计理念。 - **团队成员的能力水平**:拥有熟练掌握多种编程语言和技术框架的人才队伍可以选择更灵活但复杂的纯软件方法论反之则应优先考虑基于硬件特性的简单直观的方式。 - **预期变更频率**:预计会有较多结构调整的地方最好采取易于重构的形式以免后期改造困难重重;相反那些相对稳定的部分可以用更为严格的方式来加强保护力度。 总之,在做出最终决策前务必充分权衡各种利弊并结合实际情况作出明智的选择。 ```sql -- 创建带有物理的表例子 CREATE TABLE orders ( order_id INT PRIMARY KEY, customer_id INT NOT NULL, FOREIGN KEY (customer_id) REFERENCES customers(customer_id) ); -- 使用逻辑的情况下仅创建普通字段不做任何特殊声明 CREATE TABLE payments ( payment_id INT PRIMARY KEY, order_id INT -- 这里没有建立正式的FK关系 ); ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值