大型数据库设计剖析.pptVIP

杜威华 2010-11-25 大型数据库设计 大纲 设计基本原则 表的设计及规划 数据生命周期管理 多线程设计中的死锁问题 垂直分割与水平分割 设计基本原则 统一的命名规则 大型数据库一般对象比较多，从对象命名即可区别功能模块，采用统一的命名规则有利于设计,维护,查询 统一的书写风格 sql语句，plsql代码中大写小统一，缩进统一 列出所有字段 所有涉及表字段的书写中列出所有字段,以下方式应禁止（如果表中增加字段则下列书写的语句可能会导致问题）： select * from tab insert into tab values(xx,yy) 当然select count(*)除外 存储过程，函数，包中引用表中字段的变量，参数类型定义使用表字段类型定义 否则一旦数据类型变动，较常出问题的类似字符类型增加长度，则需要找出所有引用了变动表上的变动了数据类型的字段的所有相关对象并进行修改。 定义方式举例： vUsernumber os_user_service.usernumber%type 工 设计基本原则 相同意义字段在所有表中统一命名，使用相同数据类型 不遵循可能带来的问题： a、索引失效 b、计算列精度失真 c、维护困难 其中c有可能是带来最大的问题。以139邮箱个邮为例，手机号码是在多表中使用的字段，由于业务原因需要扩展字段长度，如果各个表中字段命名不统一则这份工作将变得相当困难。如果字段命名统一，则很简单的通过下面的查询就可以获取用户下相关的所有表进行修改了。例如在oss01用户下找出所有含有usernumber字段的表： select distinct table_name, column_name from user_tab_columns where column_name = USERNUMBER and table_name in (select table_name from user_tables) 数据类型选择遵循最小化存储及按实际选择 1、优先使用数据类型，日期类型，根据需求一定要使用字符类型的则非特殊需求情况下使用varchar2类型 2、海量数据表中字段数据类型遵循存储最小化原则，最可能存储null值的字段放在最后 3、数据类型选择遵循按实际选择的原则，例如日期类型请尽量采用日期类型存储，而不要使用字符类型代替存储 特别要注意一个原则数据类型遵循数据存储最小化原则，大型数据库中一张表中记录以亿做单位是很常见事件 ，数据类型的选择对于存储的需求的影响在记录数大的情况 下会很突出。 设计基本原则 独立功能模块Schema独立规划 对于功能模块完全独立且以后可能分离的提前规划使用不同的schema，schema间访问对象通过应用程序接口访问，禁止直接通过数据库对象引用方式。这样规划可以实现当条件具备时模块独立出来代价最小甚至透明。 例如139邮箱早期数据库全部集中于同一个schema下，带来后期进行功能模块分割时的大量不必要的工作。而当前设计则注重了schema的规划，例如群邮件，动态分区，邮件代理等新加独立功能，皆使用独立schema规划，以后如果这些模块发展良好，则可以很容易的实现垂直分割。另外独立功能模块使用独立schema还有利于定位问题。 高频引用字典表使用视图访问 避免修改字典表结构或者数据类型精度导致大量对象失效从而引发故障。 案例：号段表增加字段引发的血案 根据使用表上的DML情况 及业务规则确定序列的参数设置 cache大小设置，如非业务强制需要使用noorder 实现绑定变量 底层函数性能终极要求 通过应用程序实现数据一致性，避免使用外键 1、在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。 2、用外键要适当，不能过分追求 3、不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库。 ? 如果使用了外键，注意索引外键。当同时满足以下条件时可以不用索引外键： 没有从父表删除行 没有更新父表的唯一键/主键值 没有从父表联结子表 一般