一份来自蚂蚁金服大佬的数据库设计总结,纯干货,值得收藏( 五 )


列[字段]命名技巧
我们发现,假如你给每个表的列[字段]名都采用统一的前缀,那么在编写 SQL 表达式的时候会得到大大的简化 。这样做也确实有缺点,比如破坏了自动表连接工具的作用,后者把公共列[字段]名同某些数据库联系起来,不过就连这些工具有时不也连接错误嘛 。举个简单的例子,假设有两个表:
Customer 和 Order 。Customer 表的前缀是 cu_,所以该表内的子段名如下:cu_name_id、cu_surname、cu_initials 和cu_address 等 。Order 表的前缀是 or_,所以子段名是:or_order_id、or_cust_name_id、or_quantity 和 or_description 等 。
这样从数据库中选出全部数据的 SQL 语句可以写成如下所示:
 Select * From Customer, Order Where cu_surname = "MYNAME" ;and cu_name_id = or_cust_name_id and or_quantity = 1在没有这些前缀的情况下则写成这个样子(用别名来区分):
 Select * From Customer, Order Where Customer.surname = "MYNAME" ;and Customer.name_id = Order.cust_name_id and Order.quantity = 1第 1 个 SQL 语句没少键入多少字符 。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了 。
三、选择键和索引数据采掘要预先计划
我所在的某一客户部门一度要处理 8 万多份联系方式,同时填写每个客户的必要数据(这绝对不是小活) 。我从中还要确定出一组客户作为市场目标 。当我从最开始设计表和字段的时候,我试图不在主索引里增加太多的字段以便加快数据库的运行速度 。然后我意识到特定的组查询和信息采掘既不准确速度也不快 。结果只好在主索引中重建而且合并了数据字段 。我发现有一个指示计划相当关键——当我想创建系统类型查找时为什么要采用号码作为主索引字段呢?我可以用传真号码进行检索,但是它几乎就象系统类型一样对我来说并不重要 。采用后者作为主字段,数据库更新后重新索引和检索就快多了 。
可操作数据仓库(ODS)和数据仓库(DW)这两种环境下的数据索引是有差别的 。在 DW 环境下,你要考虑销售部门是如何组织销售活动的 。他们并不是数据库管理员,但是他们确定表内的键信息 。这里设计人员或者数据库工作人员应该分析数据库结构从而确定出性能和正确输出之间的最佳条件 。
使用系统生成的主键
这类同技巧 1,但我觉得有必要在这里重复提醒大家 。假如你总是在设计数据库的时候采用系统生成的键作为主键,那么你实际控制了数据库的索引完整性 。这样,数据库和非人工机制就有效地控制了对存储数据中每一行的访问 。
采用系统生成键作为主键还有一个优点:当你拥有一致的键结构时,找到逻辑缺陷很容易 。
分解字段用于索引
为了分离命名字段和包含字段以支持用户定义的报表,请考虑分解其他字段(甚至主键)为其组成要素以便用户可以对其进行索引 。索引将加快 SQL 和报表生成器脚本的执行速度 。比方说,我通常在必须使用 SQL LIKE 表达式的情况下创建报表,因为 case number 字段无法分解为 year、serial number、case type 和 defendant code 等要素 。性能也会变坏 。假如年度和类型字段可以分解为索引字段那么这些报表运行起来就会快多了 。
键设计 4 原则

  1. 为关联字段创建外键 。
  2. 所有的键都必须唯一 。
  3. 避免使用复合键 。
  4. 外键总是关联唯一的键字段 。
别忘了索引
索引是从数据库中获取数据的最高效方式之一 。95% 的数据库性能问题都可以采用索引技术得到解决 。作为一条规则,我通常对逻辑主键使用唯一的成组索引,对系统键(作为存储过程)采用唯一的非成组索引,对任何外键列[字段]采用非成组索引 。不过,索引就象是盐,太多了菜就咸了 。你得考虑数据库的空间有多大,表如何进行访问,还有这些访问是否主要用作读写 。
大多数数据库都索引自动创建的主键字段,但是可别忘了索引外键,它们也是经常使用的键,比如运行查询显示主表和所有关联表的某条记录就用得上 。还有,不要索引 memo/note 字段,不要索引大型字段(有很多字符),这样作会让索引占用太多的存储空间 。
不要索引常用的小型表
不要为小型数据表设置任何键,假如它们经常有插入和删除操作就更别这样作了 。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间 。
不要把社会保障号码(SSN)或身份证号码(ID)选作键
永远都不要使用 SSN 或 ID 作为数据库的键 。除了隐私原因以外,须知政府越来越趋向于不准许把 SSN 或 ID 用作除收入相关以外的其他目的,SSN 或 ID 需要手工输入 。永远不要使用手工输入的键作为主键,因为一旦你输入错误,你唯一能做的就是删除整个记录然后从头开始 。


推荐阅读