g***l
发帖数: 18555 | 1 随便总结了一下，不包括ETL,抛砖引玉了，
1. never use * in query, only use specific columns and rows you need, never
use extra
2. table uses dbo prefix, selection uses with (nolock)
3. repeated code section can be replace by UDF or stored procedure
4. join is always on the key. if join is not the key, you need to be very
careful
5. layout flow chart for complicated stored procedure before coding
6. CTE is a good choice to replace subquery, table variable and temp table
7. all the work should be done on the temp t... 阅读全帖 |
|
g***l
发帖数: 18555 | 2 换成CTE吧，保险, 而且两个表的COLUMN NAME也不一定一样
；with cte_temp(
SELECT BB as field_name from TABLEB
UNION ALL
SELECT CC as field_name from TABLEC
)
update TABLEA set ColA = 'Y'
from
TABLEA t, cte_temp c
where
t.colB =c.field_name |
|
i*****w
发帖数: 75 | 3 USE CTE (Common Table Expression) to retrieve until it's exhausted (parent -
> Child relationship).
the
and
N |
|
y****w
发帖数: 3747 | 4 oracle用connet by. 以前的CTE就是摆设，只有到11r2还是多少才完善起来。 |
|
y****w
发帖数: 3747 | 5 别烦，recursive CTE是必须要掌握的冬冬之一。
or |
|
B*****g
发帖数: 34098 | 6 一个sub用１０次，用起来还是很方便的。而且execution plan也比较好控制。
recursive的，不然和subquery除了写法没啥区别。
recursive CTE。 |
|
|
B*****g
发帖数: 34098 | 8 nod，建个type DBA都要jjww一回。而且view不行呀，每次sql要是略有不同得搞多少
view呀
里说的同一个subquery在一个sql里面被引用多次，那也是个常见用法。
的view candidate. 如果只是在一个地方用多次，dba大概不会太高兴手下的schema又
复杂了一点。 |
|
y****w
发帖数: 3747 | 9 [inline] table function is another option.
而且view不行呀，每次sql要是略有不同得搞多少 |
|
B*****g
发帖数: 34098 | 10 这里temp table和view比有什么优势？如果sql结果变化temp table不能显示变化吧。 |
|
g***l
发帖数: 18555 | 11 VIEW还是要套在TABLE上吧，即使NO LOCK，还是对TABLE有影响的，弄个TEMP TABLE自
己玩去吧，怎么添加啊更新，不管咱的事，控制数据量就可以了。 |
|
y****w
发帖数: 3747 | 12 temp笨重不灵活，但是，可以加索引。如果后继操作时间长，还可以减少lock-wait(even nolock/ur)和死锁的机会。 |
|
g***l
发帖数: 18555 | 13 用什么差别不是太大，关键还是逻辑了，碰上个脑子不清楚就为了弄结果赚点钱了事的
，就惨了，你就是把FLOW CHART给他画好，编出来的也还是五花八门。 |
|
B*****g
发帖数: 34098 | 14 别说干掉connect by，10年后能普及12g就不错了。10年后大家还在care怎么写sql？嘿
嘿。就像俺们头说的，我最多就care12g，再往后我退休了。另外，你确定１０年后还
用rd吗？
胜于无了。 多数情况下，temp table太重量级，不方便，好比拿c去拼java了。
话能少用就少用，connect by早晚deprecated。就好比rbo特色了太久，回头best
practice还是大家都用的cbo。 |
|
g***l
发帖数: 18555 | 15 嗯，还是不要强调用什么更好，没有最好只有更好，微软也弄出个什么ENTITY铺在
TABLE上，从NET里读写都很快，也利于开发，估计将来也不用SQL了，谁知道呢。 |
|
y****w
发帖数: 3747 | 16 你们头儿就是丫死后哪管洪水滔天的角色，呵呵。我要是cto就把丫开掉。 |
|
y****w
发帖数: 3747 | 17 这个帖子好像说的是具体而微的东西，干嘛扯那么不可预测的将来？呵呵。
好比给20年前的c programmer讲别玩c了研究啥算法优化啥内存啊，以后用java了，内
存便宜的很。。。。。
路还是要一步一步走到。 |
|
B*****g
发帖数: 34098 | 18 俺们公司的CTO最恨搞新技术革新的，hoho
？嘿
后还 |
|
|
y****w
发帖数: 3747 | 20 sql server的sp有encyption选项。oracle好像可以用什么wrapper. 静态的加密都有破解的可能。
再说总是有办法收集动态运行的sql的（即使是静态sql），这些放到库里去，就不保险。 |
|
|
|
|
|
y****w
发帖数: 3747 | 25 在编程语言中对核心逻辑加密，数据方面只取源数据，核心逻辑得放到自己这边来，不
能扔到数据库去跑。 |
|
|
y****w
发帖数: 3747 | 27 ok,suppose what you're working at is Quest Spotlight. |
|
B*****g
发帖数: 34098 | 28 That is why "We should not provide software, we should provide service!"
That is how oracle/ibm successed but sun failed. |
|
y****w
发帖数: 3747 | 29 open source出有用的东西，容易出名，但容易被ｃｏｐｙ，回头自己活活饿死，看着
别人大口吃肉自己连口汤都没有。尤其是核心ｖａｌｕｅ容易被ｃｏｐｙ的冬冬。 |
|
s**********0
发帖数: 266 | 30 SQL server 里不是可以写SQLCLR吗？
我现在在一个处理大量信用卡号码的公司里（PCI compliance）工作。DBA不能写code
只能deploy。 一般我都是写一些SQLCLR的 stored procedure, deploy的时候就给DBA
2个assembly dll, 叫他们先加到sql server,再从dll上建 stored procedure. 这
样DBA想看我们的encrypt/decrypt的逻辑也看不到。 一般来说DBA只管理和rotate sql
server 上的 certificate 和 symmetric keys, developer掌握着加密和解密的原理。
破解的可能。
险。 |
|
a9
发帖数: 21638 | 31 clr解密也忒容易了。
code
DBA
sql
理。 |
|
B*****g
发帖数: 34098 | 32 点net写的dll解密很难吗？赫赫
code
DBA
sql
理。 |
|
s**********0
发帖数: 266 | 33 是不难，但估计一般的DBA也没兴趣去破解。总比直接给DBA create procedure XXX
with encryption 的sql script要安全吧。
其实最后建完的stored procedure， DBA和developer大家都有execute的rights；要偷
些信用卡号码对大家来说都不难。 所以我也不知道公司（和PCI的要求）为什么要这样
搞。。。 可能也就是防防一般人进入network把整个database backup file给偷了? |
|
l******t
发帖数: 660 | 34 知道解谜的原理有什么用， 那些加密的算法都是公开的， 但是你知道算法也解不了啊 |
|
y****w
发帖数: 3747 | 35 一般的dba可能没兴趣，但假如我是他的竞争对手那就有兴趣了。
了? |
|
|
y****w
发帖数: 3747 | 37 产品的architect呢。 than project architect. |
|
s**********0
发帖数: 266 | 38 说到解密我倒想起一件事，我们单位有一个DBA差点被fire。 他在一个sql server上竟然有差不多一年没有backup 我们用来加密的 certificates 和 symmetric keys （每过一段时间要重建的）
查出来之后被骂的狗血喷头，还好server没出事，不然的话我们最重要的数据全都变
成了一堆garbage data. 公司历史上也出过一次这样的事，有一个新的project
deploy to production后我们发觉谁都不能还原OLTP server上加了密的数据 （一帮人大眼瞪小眼，谁也没办法）。 还好2天不到就发现了， 结果只能去重听所有的recording，一个一个再把所有的数据manually update回去。 噩梦啊。。 |
|
y****w
发帖数: 3747 | 39 dba也是高风险职业，有两起血案，圈子里挂上号就不好过了，磕磕。
2 |
|
|
|
a9
发帖数: 21638 | 42 也不能说不推荐吧。能不用就不用就是了。
ms也是花了力气做上去的，怎么就说不推荐呢。
这 |
|
y****w
发帖数: 3747 | 43 ncorrect syntax near the keyword 'with'. If this statement is a common
table expression or an xmlnamespaces clause, the previous statement must be
terminated with a semicolon.
---错误信息很清楚啊。
sql server里面如果你要用CTE的话，with前面必须有分号。
所以有些人的风格就是
;with xx
........ |
|
|
y****w
发帖数: 3747 | 45 没仔细看，看到with就想cte。 sql server好像见with就要加";" |
|
s**********0
发帖数: 266 | 46 CROSS APPLY 对multiple level XML很有用，他会选择所有那一个level的 nodes， 然后你可以用 .value 去读那个XML node里的 attribute value 和data value.
这个CTE只不过是把 Column ‘AllNames’ 里的数据 转换成一个XML string。 把 ‘，’之间的内容全搞成一个XML node。 其实只是一个很简单的xpath 的select而已。 |
|
p********l
发帖数: 279 | 47 You can try to use CTE and row_number:
WITH TableRN AS
(
SELECT ROW_NUMBER() OVER(ORDER BY col1) AS rownum,
col1,
col2
FROM Table1
)
SELECT rownum, col1, col2
FROM TableRN
WHERE rownum BETWEEN n1 AND n2
ORDER BY rownum; |
|
|
|
y****w
发帖数: 3747 | 50 ansi sql.
这些是用来做developer的面试题，基本sql就可以解决。还有些地方容易出错，上来一
把能写对是很不容易的。 recursive cte的问题，要么太简单要么就复杂到不适合做
面试题目。 |
|
