您现在的位置: 首页 > 网站导航收录 > 百科知识百科知识

(csdn)-数据库)-数据库类型

字段,索引,数据(csdn)-数据库)-数据库类型

发布时间：2019-02-08加入收藏来源：互联网点击：

csdn 数据库（数据库类型）CSDN2021-05-19 16:39:24

作者 | LaoYuanPython 责编 | 欧阳姝黎

出品 | CSDN原力计划

引言

笔者及所在团队从 2000 年开始的 CRM 等系统开发，一直主要使用 Oracle 数据库作为应用数据库，开发方式包括使用 PLSQL 编写存储过程/数据库函数/触发器、使用 ODBC 或 OCI 和 ProC 开发 C++应用、使用 JDBC 开发 Java 应用、使用 tuxdeo 开发中间件应用等。这些应用开发笔者所在团队自己做过，也委托华为、亚信、思特奇等国内厂商合作做过，整体来说 Oracle 数据库功能强大、性能出众、系统健壮，确实是 OLTP 联机事务处理的最受欢迎的数据库。

因 Oracle 服务费居高不下、加上国产数据库也走出了一条自己的路，因此数据库国产化也越来越被提上日程，也有部分应用走出了成功之路，但众多传统应用进行国产数据库的改造需要大量投入，也需要一个逐步试点及改造的过程，因此 Oracle 仍然是国内众多单位持续应用的选择。

今天老猿结合二十余年的 Oracle 数据库应用开发和运维的经验教训，总结在使用 Oracle 数据库环境中的应用开发中需要注意的一些注意事项，这些问题不但可以作为 Oracle 数据库开发的注意事项，大多数也适用于常见的关系型数据库开发甚至非关系型数据开发。

实际上，在数据库应用开发上，开发和维护关联度是非常大的，好的开发设计会给维护带来极大方便。因此虽然维护关注的角度和开发有所不同，但在部分内容上二者是统一的。

禁忌1：触发器代码忌复杂

数据库触发器由于可以基于表级进行所有应用或手工 DML 操作数据增删改查的前向或后向处理，易于收敛逻辑，使用方便，容易受到众多开发人员的喜爱。

但在使用上触发器与操作数据的事务处于同一个事务，因此比较适合简单处理逻辑，切忌不能在触发器上使用复杂逻辑，一般推荐在 10 行左右代码比较适合，否则容易导致事务处理出现问题。

如果一定要通过触发器进行复杂逻辑处理，最好的做法是通过触发器将需要处理的数据写入到单独的任务表中，然后使用单独进程对任务表数据进行处理。这样能使得触发器和触发源二者的事务解耦，又能收敛相关数据处理。

禁忌2：忌使用dblink

dblink 提供的机制可以使得在一个数据库的存储过程、触发器、数据库函数中方便的访问另一个数据库，可以方便地为应用只需连接一个数据库就可以访问另一个数据库中的数据，因此给多数据库环境使用带来了很大的便利性。

但 dblink 在跨数据库事务提交上容易引发问题，一般可以在不带事务的 DML 简单查询中使用，如果一定要带事务必须确保事务提交迅速，否则容易引发分布式事务锁。而应用程序中使用时，由于运行的环境复杂多变，无法百分之百保障事务的完整性和响应快速，很容易引发分布式事务锁并有一定几率触发 ORACLE 的 BUG，同时 dblink 本身会大概率甚至百分之百带来 scn 号跳变 bug，并引发 scn 号跳变在数据库间传播。导致系统故障甚至数据库瘫痪。因此不要在代码开发中使用 dblink。平时运维也尽量少用，如果一定要用最好不带事务，并尽快释放连接。

禁忌3：忌用大表关联统计

在一个系统中，除了实时类交易外，也存在一定要求数据实时的统计或查询需求，针对这种数据统计，切忌使用大表关联进行统计，因为会导致数据库消耗大量计算资源、占用过多的临时空间，影响其他实时业务的响应甚至导致系统无法响应。

对于这种需要跨多个大表的统计，最理想的是不放在 OLTP 数据库执行，如果一定要执行，一是要想办法限制数据的范围（如基于时间限制只能统计当天的），二是对于两个大表关联的 SQL 进行拆分，拆分成两个 SQL，前一个 SQL 获取的数据通过游标打开后再逐条去另一个大表使用索引逐条数据进行访问，再用客户端进行统计运算，或者通过游标获取数据生产临时表再基于临时表进行统计。

禁忌4：忌用字典式字段索引

索引只有说数据在索引字段比较分散才有效果，如果基于一些字典式字段（如性别、课程等）建索引，起不到很好的效果不说，还浪费存储空间。这种字典式的字段如果一定要发挥类似索引的效果，可以按字典值建分区键。

禁忌5：慎用主键约束

某个表的主键理论上看起来是个很好的机制，但在一般性应用中，由于主键不能更新，因此在运维时会带来很多不便，一般建议慎用，而是可以用非空和唯一性约束方式来替代。

禁忌6：慎用外键关联

外键关联可以确保某个表的主键被其他表作为非主键使用时来保障两个表数据的一致性，但外键关联给程序开发、运维都带来了更多的复杂性，而好的开发习惯能确保两个有外键关联的表满足数据一致性的要求，因此一般情况下慎用外键关联。这其实是根据在方便性、数据一致性之间应用更倾向于哪方面来决策使用方式。

禁忌7：组合索引使用要注意

使用多个字段的混合索引是常见的，但索引使用的字段越多，就意味着开发时需要关注的字段越多，开发时部分人员容易忘记索引字段，导致容易写出用不到索引的语句。因此一般建议复合索引使用字段不超过5个；

组合索引中字段的顺序是非常重要的，越是唯一的字段越是要靠前；

程序代码使用组合索引时，在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，并且应尽可能的让字段顺序与索引顺序相一致。

禁忌8：慎重考虑表字段调整

当一个初始设计的表在运行一段时间后，随着业务的发展和系统的持续运营，对表结构进行调整是迟早的事，但调整表结构如增加新字段、字段长度调整等都需要慎重，特别是针对数据量大访问频繁的表更要谨慎。

在评估表结构调整时，一般需要考虑：

是否需要停系统调整，对于高并发访问频繁的表至少要等到业务闲时进行调整；

如果是调整字段大小需要评估是否有代码限制了字段大小；

如果是新增字段需要评估是否有代码采用了 select *方式访问；

是否需要初始化历史数据？如果有是否会造成行迁移？是否需要重建表？

是否会影响外围接口或系统数据的交互？

为了应对字段增加可能带来的风险，有2个方法来提取预防：

给一些大表预留一定的字段，这样可以避免停系统、减少行数据迁移、并避免系统运行时进行表结构调整的风险，但要规划好预留字段的数量、并做好启用管理；

尽量不动大表本身，而是设计扩展表来解决。

禁忌9：忌直接使用用户名和密码连接数据

在信息安全非常重视的今天，数据库的安全性是重中之重，应用系统不应该在程序代码或配置文件中直接使用用户名和密码方式连接访问业务数据。如果这样，对开发人员和维护人员密码就和没有密码一样，另外如果出现数据库必须修改密码时，需要到处改密码相关的代码或配置文件。

比较好的解决办法是用最小权限的用户登录，登录后通过专用加密配置表获取用户真正使用的用户和密码，这就是二次登录。

 1/3    1 2 3 下一页 尾页