g*****1
发帖数: 998 | 1 比如需要写correlated subquery的时候，总写不太好。
一般都是一次写出来吗？有什么套路吗？还是完全凭感觉？谢谢 |
g***l
发帖数: 18555 | |
h**********c
发帖数: 4120 | 3 做题的话，relational algebra挺有用，
不知道实践中大公司用不用。
以前看公司实际的dbase iii，多半是写很长的procedure,生成比较简单的临时表，
或者常用的查询干脆写好库，每天夜审时更新，
当然这种酒店级别的数据库都不大，几十mega，一百出头。跟google,facebook的库没
法比。
【在 g*****1 的大作中提到】
: 比如需要写correlated subquery的时候，总写不太好。
: 一般都是一次写出来吗？有什么套路吗？还是完全凭感觉？谢谢
|
y****w
发帖数: 3747 | 4 normally we prefer to resolve our problem with as few as sql statement.
but the reality is, most dbmses are lack of as good as enough optimization
for those 'intermediate' table, I call it 'indexed CTE' . this is very common if you're working on BI projects and
need to deal with large volume of data.
but the fact could be simpler, it's always easier to be developers using a
lot of temp tables than one who
always trying to write short effecient sql.
【在 h**********c 的大作中提到】
: 做题的话，relational algebra挺有用，
: 不知道实践中大公司用不用。
: 以前看公司实际的dbase iii，多半是写很长的procedure,生成比较简单的临时表，
: 或者常用的查询干脆写好库，每天夜审时更新，
: 当然这种酒店级别的数据库都不大，几十mega，一百出头。跟google,facebook的库没
: 法比。
|
y****w
发帖数: 3747 | 5 good relational algebra background may help a lot. you may avoid a lot
trouble when dealing with
complicated logic, for example, multiple join + complicated join condition +
NULL + pivot/unpivot.
【在 h**********c 的大作中提到】
: 做题的话，relational algebra挺有用，
: 不知道实践中大公司用不用。
: 以前看公司实际的dbase iii，多半是写很长的procedure,生成比较简单的临时表，
: 或者常用的查询干脆写好库，每天夜审时更新，
: 当然这种酒店级别的数据库都不大，几十mega，一百出头。跟google,facebook的库没
: 法比。
|
h**********c
发帖数: 4120 | 6 觉得数据库高手一定都是离散数学高手，一定是说老兄了。
+
【在 y****w 的大作中提到】
: good relational algebra background may help a lot. you may avoid a lot
: trouble when dealing with
: complicated logic, for example, multiple join + complicated join condition +
: NULL + pivot/unpivot.
|
y****w
发帖数: 3747 | 7 试图在路上而已了。离真正的高手还差得远。
【在 h**********c 的大作中提到】
: 觉得数据库高手一定都是离散数学高手，一定是说老兄了。
:
: +
|
