g***l
发帖数: 18555 | 1 其实我发现了CODE的写得好不好，不能只看出不出结果
*第一个是思路要清楚，谁JOIN谁，KEY是什么，什么JOIN，
*我的目标是什么，进来的是什么参数，出去的是什么
*复杂的QUERY,先把FLOW CHART画好，
大家讨论一下，看看有没有什么更好办法， SUBQUERY放到CTE或者TEMP TABLE里，
*不挂不需要的数据和COLUMN
*避免用*，避免用CURSOR，避免长时间的，或者繁琐的UPDATE DELETE (JOIN)
*READ ONLY一律用WITH (NOLOCK)
*容错性，进来的错参数会不会出烂数据,表中有错数据，会不会ERROR OUT
*最后看扩展性，再加个参数要花多长时间改。 |
y****w
发帖数: 3747 | 2 nice。
有些是不可能兼顾的。比如最后一条就经常成为性能杀手。不过对dba script来说，这个就又非常实用，单条性能就是慢上三五秒也不会让我发狂。
大家讨论一下，看看有没有什么更好办法， SUBQUERY放到CTE或者TEMP TABLE里，
--------这个现有的dbms解决的都不太好，多层查询中间结果的join经常会是性能瓶颈
。 我做过些简单的尝试，以函数封装subquery，借助temp table实现indexed CTE。效
果还不错，限制也很多，只能用于比较简单的情况。dbms厂商在sql compiler里加上
index hint要容易的多。
【在 g***l 的大作中提到】
: 其实我发现了CODE的写得好不好，不能只看出不出结果
: *第一个是思路要清楚，谁JOIN谁，KEY是什么，什么JOIN，
: *我的目标是什么，进来的是什么参数，出去的是什么
: *复杂的QUERY,先把FLOW CHART画好，
: 大家讨论一下，看看有没有什么更好办法， SUBQUERY放到CTE或者TEMP TABLE里，
: *不挂不需要的数据和COLUMN
: *避免用*，避免用CURSOR，避免长时间的，或者繁琐的UPDATE DELETE (JOIN)
: *READ ONLY一律用WITH (NOLOCK)
: *容错性，进来的错参数会不会出烂数据,表中有错数据，会不会ERROR OUT
: *最后看扩展性，再加个参数要花多长时间改。
|
u***t
发帖数: 3986 | 3 先把order by砍掉
【在 g***l 的大作中提到】
: 其实我发现了CODE的写得好不好，不能只看出不出结果
: *第一个是思路要清楚，谁JOIN谁，KEY是什么，什么JOIN，
: *我的目标是什么，进来的是什么参数，出去的是什么
: *复杂的QUERY,先把FLOW CHART画好，
: 大家讨论一下，看看有没有什么更好办法， SUBQUERY放到CTE或者TEMP TABLE里，
: *不挂不需要的数据和COLUMN
: *避免用*，避免用CURSOR，避免长时间的，或者繁琐的UPDATE DELETE (JOIN)
: *READ ONLY一律用WITH (NOLOCK)
: *容错性，进来的错参数会不会出烂数据,表中有错数据，会不会ERROR OUT
: *最后看扩展性，再加个参数要花多长时间改。
|
B*****g
发帖数: 34098 | 4 我现在发现，如果design太烂的话，code再好也没用。有时真怀疑设计系统的人学没学
过数据库。
【在 g***l 的大作中提到】
: 其实我发现了CODE的写得好不好，不能只看出不出结果
: *第一个是思路要清楚，谁JOIN谁，KEY是什么，什么JOIN，
: *我的目标是什么，进来的是什么参数，出去的是什么
: *复杂的QUERY,先把FLOW CHART画好，
: 大家讨论一下，看看有没有什么更好办法， SUBQUERY放到CTE或者TEMP TABLE里，
: *不挂不需要的数据和COLUMN
: *避免用*，避免用CURSOR，避免长时间的，或者繁琐的UPDATE DELETE (JOIN)
: *READ ONLY一律用WITH (NOLOCK)
: *容错性，进来的错参数会不会出烂数据,表中有错数据，会不会ERROR OUT
: *最后看扩展性，再加个参数要花多长时间改。
|
a***y
发帖数: 2803 | 5 最怕数据里面有NULL的,一有运算就要写NVL( ,0). 闹心.如果数据多,这个NULL就是个地雷.而且not in的subquery里面不能有null,跟null有关的地方都会发虚.
left outer join,right outer join,full join我倒是不怕.
【在 g***l 的大作中提到】
: 其实我发现了CODE的写得好不好，不能只看出不出结果
: *第一个是思路要清楚，谁JOIN谁，KEY是什么，什么JOIN，
: *我的目标是什么，进来的是什么参数，出去的是什么
: *复杂的QUERY,先把FLOW CHART画好，
: 大家讨论一下，看看有没有什么更好办法， SUBQUERY放到CTE或者TEMP TABLE里，
: *不挂不需要的数据和COLUMN
: *避免用*，避免用CURSOR，避免长时间的，或者繁琐的UPDATE DELETE (JOIN)
: *READ ONLY一律用WITH (NOLOCK)
: *容错性，进来的错参数会不会出烂数据,表中有错数据，会不会ERROR OUT
: *最后看扩展性，再加个参数要花多长时间改。
|
a***y
发帖数: 2803 | 6 恩,学linux的时候也有同感,老师说可能是在pub里边喝酒边写code.
【在 B*****g 的大作中提到】
: 我现在发现，如果design太烂的话，code再好也没用。有时真怀疑设计系统的人学没学
: 过数据库。
|
y****w
发帖数: 3747 | 7 linux??
【在 a***y 的大作中提到】
: 恩,学linux的时候也有同感,老师说可能是在pub里边喝酒边写code.
|
a***y
发帖数: 2803 | 8 很多时候写出了select statement,语法是正确的,但是不知道结果是正确的,怎么办?
能不能有个什么测试用的database?
【在 g***l 的大作中提到】
: 其实我发现了CODE的写得好不好，不能只看出不出结果
: *第一个是思路要清楚，谁JOIN谁，KEY是什么，什么JOIN，
: *我的目标是什么，进来的是什么参数，出去的是什么
: *复杂的QUERY,先把FLOW CHART画好，
: 大家讨论一下，看看有没有什么更好办法， SUBQUERY放到CTE或者TEMP TABLE里，
: *不挂不需要的数据和COLUMN
: *避免用*，避免用CURSOR，避免长时间的，或者繁琐的UPDATE DELETE (JOIN)
: *READ ONLY一律用WITH (NOLOCK)
: *容错性，进来的错参数会不会出烂数据,表中有错数据，会不会ERROR OUT
: *最后看扩展性，再加个参数要花多长时间改。
|
B*****g
发帖数: 34098 | 9 写完sql当然要测试
【在 a***y 的大作中提到】
: 很多时候写出了select statement,语法是正确的,但是不知道结果是正确的,怎么办?
: 能不能有个什么测试用的database?
|
m******y
发帖数: 588 | 10 不错。
加一条，如果写很长的sp, 最好有个@debug flag可以turn on/off, code里有debug信
息，以后有问题时可以比较容易解决，也比较方便以后的人看你的code。
【在 g***l 的大作中提到】
: 其实我发现了CODE的写得好不好，不能只看出不出结果
: *第一个是思路要清楚，谁JOIN谁，KEY是什么，什么JOIN，
: *我的目标是什么，进来的是什么参数，出去的是什么
: *复杂的QUERY,先把FLOW CHART画好，
: 大家讨论一下，看看有没有什么更好办法， SUBQUERY放到CTE或者TEMP TABLE里，
: *不挂不需要的数据和COLUMN
: *避免用*，避免用CURSOR，避免长时间的，或者繁琐的UPDATE DELETE (JOIN)
: *READ ONLY一律用WITH (NOLOCK)
: *容错性，进来的错参数会不会出烂数据,表中有错数据，会不会ERROR OUT
: *最后看扩展性，再加个参数要花多长时间改。
|
