SQL Design Pattern - TBC

1. Alias 作为接口.

尽量使用别名，一旦某一个数据源表变化了，可以改底层源表，而无需修改使用别名的接口。

Alias有列的和表的。 都需要。一旦列和表名字更换了，别名不会让后续代码修改。

举例：

CREATE TMP TABLE VT_A AS

(

SEL

  mycol_a AS a

, mycol_b AS b

FROM tableX

)

;

 

SEL COUNT(a) FROM VT_A;

如果不用别名的话，源表改为tableY之后，那么需要在后续查询语句中把a替换为yourcol_a;

 

2. 避免使用CREATE TABLE xxx AS.

当不知道CREATE TABLE ... AS的特性时，请使用手工写DDL在populate数据进该表。否则，使用这种语法快捷方式可能获得的表定义与你所认为的不一样。

 

3. De-dup 的标准

有时候Join后数据行会变多，那么可能需要过滤掉重复数据，过滤准则一般是按照Join后的Schema的PK进行划分窗口。每个窗口按照业务规则进行排序去一条数据。

 

4. 关于NULL

NULL是一个很不好的值，所以在设计表的时候，尽量不要把列定义为NULLABLE，尽可能的定义为NULL。有时候可以把NULL转换为一个非差值，如-999。否则，对于NULLABLE 列要用COALESCE(COL, -999)来做JOIN条件。

 

5. 开发复杂逻辑表的方法论

--5.1 理解逻辑：制作用例，实际的例子描述逻辑流程的运作。然后，对于边界的示例也是很重要的。

--5.2 编写易于理解的算法代码，不用考虑性能

--5.3 debug与verification：实体化任何可能的中间表，中间表易于分析各种用例的正确性

--5.4 集成代码优化代码，包括性能部分。

--5.5 优化好的代码的结果集与非优化好的代码进行比较，做好前后数据一致

--5.6 为代码编写注释，以及可能的话包括文档。

 

6. 在开发过程中尽可能多的使用约束

开发过程中是要发现问题，尤其是数据质量问题，如果待上线后用户发现数据质量问题，那就开发而言，这是个拙劣的开发。

如何避免数据质量问题？除了高效准确的QA环节外，开发过程中在表级以及列级应用约束可能很好地避免大部分的数据质量问题。

 

比如，有三个列有这样的关系：A+B=C,那么可以用check子句来进行约束。再如，A的范围区间是0~12，check子句也是起到很好的作用。

 

查看DB支持约束的种类与级别，尽可能地运用DB的内嵌功能完成数据质量的校验，不用人工复查。事半功倍。

 

7. 复杂逻辑转换的设计原理

7.1 - 把所有列的计算封装到中间工作表中

7.2 - 最终目标表只是简单的集成，千万不要在目标表的集成过程中计算状态量或者做任何转换，这样会破坏松耦合性。

7.3 - 依赖关系图- TBC

 

8. 关于Staging table 和 Working Table

在我的设计原则中，Staging table要卸去所有的约束，即很简单的表，每个字段为NULLABLE，长度够长。这是为了让文本文件可以很容易地加载到数据库中来。

Working table必须要有确保数据质量的很多约束，包括Unique，Check，Assertion等等。约束还可以体现在populate working table的逻辑过程中，比如volatile的约束限制上。

以上的这些个原则，stg无约束是为了让数据加载进来，当working table发现有数据质量问题的时候很容易地查看stg的内容。因为看stg肯定是比看文本文件来得容易多。

 

9. 关于测试QA

很多时候我们会想到production上进行测试，这是因为production有真实的数据，可以省下很多因为测试而准备数据的时间。

一般，我们会在production上分出一块sandbox的数据库，这块sandbox内可以创建working table和target table来模拟ETL流程。

 

就我目前涉及到的系统，prod上不仅有dev sandbox，又有给用户用的原型sandbox，这个时候，一定要谨记dev sandbox可以当做QA用，但是用户Sandbox不可以。否则，容易破坏用户sandbox的数据导致用户的report（mockup）发生错误。 而作为一次性的数据登陆点（如historical landing point），两者倒是可以随便使用。