

首页  思维导图  详情



数据分析-sql生成

2019-03-05 14:03:37   0  举报





仅支持查看

AI智能生成

sql拼接

sql

模版推荐

作者其他创作

大纲/内容

迭代策略

目标

快速

扩展性

步骤

主键生成策略

主键支持1vm

原来是1v1

思考：是否支持多主键

成本

如果列与mainTable的关联做好，成本很小

主键之间的关联关系？

笛卡尔积？

不靠谱

关联所有字段，如果所有字段为null，则去掉这一行

层级关系？（不考虑）

靠谱

可以设置一个parent_key的字段

关系如何拿？

来自一个映射表？

根据字段规则

没必要

来自一个表的关联关系

比如：pid,vid

pid和vid的关联关系通过visit_med_summary表关联

其实也不全对，vid可以单独做主键，这里是做说明

这样，一条sql就应该搞出来

具体功能

1v1

很简单，现在已经支持

1vm

多个主键来自多个表的不同字段

现在已经支持1vm的列sql，主键sql去掉关联字段即可

mv1

多个主键来自一个表的不同字段

单条sql即可

mvm

多个主键，来自多个表的不同字段

单条sql即可

各种情况混合

实现方案

判断是否是多主键

count conf['pk']

是

找到一个表的关联关系

找到层级关系

找到关联表

看是否有parent field字段

单个列提取

上面3步生成的数据做笛卡尔积

如果做笛卡尔积？

cross join

否

1v1？

easy

1vm？

多个1v1 join

如何判断

type = 1vm？

生成map主表列表，主属性的对应关系

添加外键：opk功能

外键和主键一起生成还是自己单独生成再join主表

单独好一些

外键优先join

外键不需要单独拎出

外键的循环依赖问题

权重？

程序获得？

遍历所有外键，查看是否依赖其他外键？

如果有依赖，需要梳理出依赖关系图

不能有循环依赖

即使配置权重也要校验循环依赖的问题

或者说权重大的引用权重小的

可以程序自动加权重

无外键依赖、权重为1，最高权重

有依赖，则权重为依赖的权重和

计算依赖权重为1的外键

经过上面2步，如果外键存在依赖未知权重的opk依赖，报错

预处理是把外键的依赖搞清楚

生成依赖的外键列表

生成外键权重列表

外键join的依赖字段必须是外键或者主键，其他的报错

分文件，改成面向对象模式

conf

生成sql

主运行脚本

优势

可以共享变量

正常列的生成方法

分析con

表

主表

中间表

本列map表

关联字段

con和关联字段没有关系

但有一个约束

最终要关联到主表

可以多条线路到1个主表

可以多条线路到多个主表

需要程序检查这个配置

以后会从后台，添加，默认会有这个约束

这个功能先搁置

con通过|分隔，每个单元对应一个join表

分析出关联字段

关联表

join主表的情况下要分析出跟主键的对应字段

map_key_field=>pk

join中间表要分析出跟外键的对应关系---伪命题、必须都得到主表

外键不应该作为中间过度字段

这里需要检查配置的合法性

生成连接链条

1vm的情况关联字段用^分割

sel 字段

列字段

1v1

1vm

关联字段

外键

主键

from、join

列map表

关联中间表

主表

一条con，一个表，on就是con单元，表要自己提取出来

join的顺序如何确定

从列属性出发，终点是主属性

先初始化生成一个链条

where子句

用|分割1vm的情况

考虑特殊情况

比如include这种配置

括号问题

允许加更灵活

平台输入的时候肯定是个数组

改成数组吧

udf字段废弃

具体工作

getsql

列名，列配置，总体配置

获得selstr

是否为特殊类型

调用特殊类型处理函数

正常类型转换数据类型

获得关联字段

分析constr

主表

中间表

列表与中间表的关联字段

列表

关联字段

过滤字段

特殊处理

udf过滤字段

解除pid，vid的依赖

获得该列对应的主键字段映射

查表获得映射字段

步骤

获取conf

通过http方式获得配置

初始化conf

空白字段补上

map里面的配置是否要都填上

先不要，可以设置优先级

初始化pk

主属性与主表对应关系

table->field->key

初始化opk

rank?

先忽略这种问题，留下接口

table->field->opk

初始化constr

拆分

最后需要保留的字段，及其映射的pk or opk

每个分组最终会链接到主表上，链接点可能是不同的key，也可能是opk

不同的连接点应该生成不同的数据集最后合并到主分支上

分组按照主分支的连接点划分

多个配置分组可能属于同一个连接点

提取合并点即可

初始化filter

主要是特殊udf函数

include

全部用like替换

array_exist

提取方式

正则？

要不要拆分？

必要性

可以先正则匹配，最后全文替换

初始化action

生成单条sql

1v1类型

select f from maintable

多pk之间的链接关系

自然链接

笛卡尔积

no pk

select f, key from t join t1 on xx join m on xx where filter

如果有多个主分支的切入点，则都放入一个子sql数组，分别切入主分支

1vm类型

1v1 union 1v1 ？

废弃

采用多个sql，分别切入主分支

flag类型

flag value为true或者false

没有映射字段，满足条件即为true，不满足为false

如何表中是否为flag类型

field_type吗？

字段名字？

字段名字好像更自然

约定好于配置

用字段名来确定flag类型，如果以"_flag"结尾的dim，就是flag类型

具体步骤

生成pksql数组

生成opksql数组

生成nomal sql 数组

具体单元

selstr

pk与no pk 只有一个不同点，就是pk不需要连接主分支的属性

flag

true or false, key

other

field, key|opk

特殊类型处理

每种类型对应一个udf

from str

join str

where str

和from str要对应

每个链条都有一个where str

组装

sql合并

每列单独生成最后join一起策略

主键策略

单表单主键

多表单主键

多表多主键

单表多主键

join策略

join单主表

存储主键之间的对应关系

join多主表

多主表，同一字段

多主表不同字段

结论

只要主表，单列生成期间都不用join

但是要找出主键字段

存储出该列原表与主键之间的对应关系

join的表中既有主表，又有中间表

中间表肯定要join到主表上

分辨原表、中间表、主表及其对应字段

原表与中间表join，取出最终关联主表的字段和目标列字段

存储字段与主属性的关系

必须存储，原来默认是pid、vid是比较low且有局限性的办法

找到目标表与中间表

找到关联关系

生成列sql

先考虑是否必要

避免方法

如果取一个表中没有pk和opk的字段，只有多表关联

有这种需求吗？

原则上有

constr的解析方法

根据|分割

根据^分割

根据=分割

找到所有的主表，及其pk，opk

跟map_table对比，找到目标表

其余都是中间表

一定要封装成函数，方便以后更改配置规则

filter策略

边界：filter只能是目标表和中间表的过滤条件

 Collect

Get Started

小白入门数据分析学习计划

 Collect

Get Started

数据分析

 Collect

Get Started

数据分析流程图

 Collect

Get Started

济宁能源数据分析流程设计





0 条评论

下一页