如果我再做DBA（二）.pdf
5墨值下载
如果我再做DBA
（二）
本文下篇将主要讲述如果我再做DBA，在设计开发领域如何作为。本文内容主要缘于我数
十年的IT服务经验总结，既有很多IT系统问题缘于设计开发源头而无法在生产系统作为的无
奈，也有全身心、全生命周期投入到项目建设前期的尽情发挥。我想我的工作风格和本文叙述
的具体内容与当下业内很多DBA和开发人员还是有一定的不同，无意对同行们提出苛求，仅畅
想自己的思路，供大家参考而已。
1. DBA在数据库设计方面的工作内容
数据库逻辑设计案例分享
职场数十年，我见过太多由于数据库逻辑设计等基础性问题而导致的IT系统严重后果。本
文举例如下，某银行的日终处理性能差就是如下一条语句所导致：
update pub_accountinginfo p
set p.extfld1 = '20161105_990007_01'
where p.subjectcode = '211010000001'
and (p.pltdate || lpad(p.plttime, 6, '0') > '20161103162000')
and (p.pltdate || lpad(p.plttime, 6, '0') <= '20161104162000')
and p.extfld1 is null
and exists
(select 1
from pub_accountinginfo s
where s.subjectcode = '301070000005'
and s.pltdate || lpad(s.plttime, 6, '0') > '20161103162000'
and s.pltdate || lpad(s.plttime, 6, '0') <= '20161104162000'
and s.accountserial = p.accountserial)
语句现有执行计划很简单，就是对pub_accountinginfo表进行了两次全表扫描。从语句条
件部分可分析，原来是要对2016年11月03日16：20到2016年11月04日16：20一天24小时数据进
行处理，显然全表扫描不合理。问题好像是语句中错误地使用了拼接操作符（||）和lpad函
数，导致无法使用相关索引，实则是数据库逻辑设计问题。具体而言，就是数据库设计者不了
解Oracle的Date类型实际上包含了Date和Time两类信息，完全没必要将时间和日期分别用
pldate和plttime两个字段并以字符类型来表示。
正确的解决方案是将pltdate字段设计为Date类型，取消plttime字段，然后语句修改如
下：
update pub_accountinginfo p
set p.extfld1 = '20161105_990007_01'
where p.subjectcode = '211010000001'
and p.pltdate between to_date('20161103162000', ‘YYYYMMDDHH24MI' )
and ('20161104162000‘,‘YYYYMMDDHH24MI')
and p.extfld1 is null
and exists
(select 1
from pub_accountinginfo s
where s.subjectcode = '301070000005'
and p.pltdate between to_date('20161103162000', ‘YYYYMMDDHH24MI' )
and ('20161104162000‘,‘YYYYMMDDHH24MI')
and s.accountserial = p.accountserial)
再创建pltdate 字段索引或者（ pltdate,subjectcode ）组合索引，Oracle将按新建索
引进行访问，性能得到极大提升。
该案例实际上也是业内普遍存在的日期数据不用Date类型而用数字、字符类型进行表示的
典型负面案例。用数字、字符类型表示日期数据不仅存在该案例的日期数据转换带来的无法使
用索引问题；还存在无法合理使用日期函数和日期表达式的计算问题，例如通过last_day(日
期数 据)可计算出该日期数据的月末 最后一天；还有无法进行日 期数据校验问题，例如
20240230可输入到数字或字符字段中而无法输入到Date字段中；还可能误导Oracle优化器产生
错误的执行计划。例如年终决算时需查询20231231至20240101之间的数据，用Date类型表示日
期数据，Oracle将计算为间隔一天，优化器会合理使用索引。如果用数字、字符类型表示日期
数据，则计算为间隔20240101 – 20231231 = 8870天，很可能误导优化器走全表扫描了。
因此，如果我作为开发和应用DBA，在数据库逻辑设计中，我一定会要求开发团队按事物
本身规律合理设计字段类型，该数字就数字类型，该字符就字符类型，该日期就Date类型。为
什么业内那么多开发人员非要拧巴着将日期数据设计成数字或字符类型，然后转换来、转换
去，最后折腾出那么多问题呢？实在令我费解。
数据库逻辑内容和方法
数据库逻辑设计不仅包括上述案例展示的正确设计字段类型内容，而且还包括3个范式的
基本规范。如果我作为开发DBA，我会让我的团队尽量遵循数据库规范化设计理论，至少不会
在一个字段中用逗号等隔离符存储信息，也不会让SQL语句中出现大量substr、trim等函数，
因为不仅会导致无法使用索引问题，而且问题根源就是数据库设计没有遵循第一范式（1NF）
即确保字段信息的原子化。例如，在《陪客户过年关的二三事》一文的故事三就是数据库设计
者将多段业务信息都塞到一个LOB字段中，导致不得不进行多次大表连接的严重性能问题。
在数据库逻辑设计中我还会大力推荐主外键技术的运用，因为这样不仅能确保业务数据的
一致性 ，而且 是实施Reference分 区、Sharding架 构等技 术的 基 础。我还会 强调check、
constraint等技术的运用，而不是把数据质量控制都依托应用软件层实现，因为这样一方面可
以简化应用软件开发工作量，另一方面也是在数据库层面加强数据质量控制。试想如果客户绕
过应用软件层面，直接进入数据库胡乱输入或修改数据，岂不是没有数据质量和安全性控制而
言？针对图片、图像、视频等大量非结构化数据，我还会积极采用LOB对象技术，并进行精心
设计和开发，既确保各种类型数据存储和管理的一体化，也确保性能最佳。
上述数据库逻辑设计内容和思路可能与目前大部分客户的技术运用策略背道而驰，即更多
的同行们是尽量不采用外键、check、constraint、LOB等数据库层面技术，弱化数据库功能，
而是通过应用软件去实现和弥补。我想主要原因还是缘于大家对性能的担忧和对数据库功能理
解的不深刻。放下包袱，按照事物本身规律去进行设计吧，但在每项技术、每个技术领域都深
入研究，精心实施。一句话：胆大心细。
数据库设计的一个故事
若干年前我参加了某全国数据库技术大会，开源和国产化数据库技术已经风起云涌，我走
入名声鹊起的某国产数据库技术交流分会场，演讲者正在讲解其数据库逻辑设计的灵活性，其
大意是在国家电网采电系统的研发中，由于该系统是每隔1分钟采集一次电表数据，一天就需
要采集24*60=1440次数据。由于应用软件开发商将每个电表一天采集的电表数据设计成一行记
录，即需要设计1440个字段，而当年的Oracle 11g只支持最多1000个字段，因此Oracle满足不
了这种设计需求。于是，演讲者说其国产数据库可以突破1000个字段的限制，这也是相比
Oracle的一个技术优势。当时我就不以为然走出了会场，为什么要迎合某些国内应用软件开发
商低劣的设计理念呢？为什么不把一天采集的1440次数据以1440行而不是1440个字段来表示
呢？这样性能更好，数据模型更灵活。如果采集频率提高到半分钟一次，难道要对相关表再增
加1440个字段吗？众所周知，在一个海量数据的表中增加一个字段和增加一条记录的性能开销
差异是无法比拟的，因此最好的策略就是采取列转行技术。
尽管日后我知道Oracle后续版本早就突破了1000个字段的限制，例如12c可以支持50000
列，19c可支持到65535列，但我肯定不会让我的设计团队设计这么臃肿、性能低下、难以管理
和维护的表结构。针对业务可能频繁变更的数据，最好的策略是用记录而不是用字段来表示，
即列转行技术，因为频繁修改表结构的代价是巨大的。在某些场景下，我还会根据字段的访问
频度采取分表策略，即将经常访问的字段设计成业务主表，访问频度不高的字段设计成业务副
表。
总之，数据库模型设计不能简单映射业务需求，而应该是在满足业务需求基础上的一种升
华和提炼，更需要确保访问性能、降低数据冗余、保证数据一致性、实现易扩展性和可管理性
等综合目标。
精雕细琢：数据库物理设计
of 7
5墨值下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
相关文档
评论