y****w
发帖数: 3747 | 1 滥用CTE,把整个过程逻辑都一层层放到cte里面了。连最普通的源表上project逻辑都要
用一层cte包起来。我数了数大概一个sql语句用了30-40层。
那一块不重要，性能好十倍差十倍也没关系，边边角角，不然肯定打回去让他重写了。
我都怀疑是不是老印们都一个培训班毕业的，好几个都这个风格。估计都是当初被填鸭
了，面试的时候可以振振有词的讲：1)精通cte 2) 1-sql solution. 听起来还是蛮牛
的。 |
B*****g
发帖数: 34098 | 2 以前传说只用sql的是大牛，所以cet套sub，sub再套cte，性能也不见的就好。
【在 y****w 的大作中提到】
: 滥用CTE,把整个过程逻辑都一层层放到cte里面了。连最普通的源表上project逻辑都要
: 用一层cte包起来。我数了数大概一个sql语句用了30-40层。
: 那一块不重要，性能好十倍差十倍也没关系，边边角角，不然肯定打回去让他重写了。
: 我都怀疑是不是老印们都一个培训班毕业的，好几个都这个风格。估计都是当初被填鸭
: 了，面试的时候可以振振有词的讲：1)精通cte 2) 1-sql solution. 听起来还是蛮牛
: 的。
|
y****w
发帖数: 3747 | 3 cte套多了性能肯定不好。现在的dbms大多不够聪明能够自动给join列加个索引再跑。有时候也怀疑这些做引擎的家伙们缺少field经验。
我是比较喜欢pure sql solution的，能用sql sp就用sql sp，不够用了再去借用java甚至c一下。不过这玩意儿也严重和应用性质有关系，自产自用也就算了，要是deliver给客户呢，怎么保护ip就是一个大问题，比如你辛辛苦苦搞一套db监控软件，不注意保护的话人家好点的dba轻轻松松把你的sql都给抠出来了。
我也只是客串过半年的db developer，经验有限的很，还是在旁边动嘴多一些。 beijing你多讲讲。
【在 B*****g 的大作中提到】
: 以前传说只用sql的是大牛，所以cet套sub，sub再套cte，性能也不见的就好。
|
s**********0
发帖数: 266 | 4 我觉得CTE最大的好处是你可以用recursive CTE。 一般来说如果有一段code要重复用
的话我都会直接建一个View。 （或者丢到table variable或temp table 里去) |
y****w
发帖数: 3747 | 5 re recursive. 我说起cte来一般就默认recursive。。。 刚才beijing在另一个帖子里说的同一个subquery在一个sql里面被引用多次，那也是个常见用法。
建view,很多developer/application不会有权限的。如果在很多地方用到，那是个好的view candidate. 如果只是在一个地方用多次，dba大概不会太高兴手下的schema又复杂了一点。
【在 s**********0 的大作中提到】
: 我觉得CTE最大的好处是你可以用recursive CTE。 一般来说如果有一段code要重复用
: 的话我都会直接建一个View。 （或者丢到table variable或temp table 里去)
|
B*****g
发帖数: 34098 | 6 nod，建个type DBA都要jjww一回。而且view不行呀，每次sql要是略有不同得搞多少
view呀
里说的同一个subquery在一个sql里面被引用多次，那也是个常见用法。
的view candidate. 如果只是在一个地方用多次，dba大概不会太高兴手下的schema又
复杂了一点。
【在 y****w 的大作中提到】
: re recursive. 我说起cte来一般就默认recursive。。。 刚才beijing在另一个帖子里说的同一个subquery在一个sql里面被引用多次，那也是个常见用法。
: 建view,很多developer/application不会有权限的。如果在很多地方用到，那是个好的view candidate. 如果只是在一个地方用多次，dba大概不会太高兴手下的schema又复杂了一点。
|
y****w
发帖数: 3747 | 7 [inline] table function is another option.
而且view不行呀，每次sql要是略有不同得搞多少
【在 B*****g 的大作中提到】
: nod，建个type DBA都要jjww一回。而且view不行呀，每次sql要是略有不同得搞多少
: view呀
:
: 里说的同一个subquery在一个sql里面被引用多次，那也是个常见用法。
: 的view candidate. 如果只是在一个地方用多次，dba大概不会太高兴手下的schema又
: 复杂了一点。
|
g***l
发帖数: 18555 | 8 CTE只是用来替代复杂的SUBQUERY，临时放在内存里，用完就扔掉，如果要反复用的话
，还是建个TEMP TABLE |
B*****g
发帖数: 34098 | 9 这里temp table和view比有什么优势？如果sql结果变化temp table不能显示变化吧。
【在 g***l 的大作中提到】
: CTE只是用来替代复杂的SUBQUERY，临时放在内存里，用完就扔掉，如果要反复用的话
: ，还是建个TEMP TABLE
|
g***l
发帖数: 18555 | 10 VIEW还是要套在TABLE上吧，即使NO LOCK，还是对TABLE有影响的，弄个TEMP TABLE自
己玩去吧，怎么添加啊更新，不管咱的事，控制数据量就可以了。
【在 B*****g 的大作中提到】
: 这里temp table和view比有什么优势？如果sql结果变化temp table不能显示变化吧。
|
|
|
y****w
发帖数: 3747 | 11 temp笨重不灵活，但是，可以加索引。如果后继操作时间长，还可以减少lock-wait(even nolock/ur)和死锁的机会。
【在 B*****g 的大作中提到】
: 这里temp table和view比有什么优势？如果sql结果变化temp table不能显示变化吧。
|
y****w
发帖数: 3747 | 12 作为subquery替代功能，我倾向于相信CTE会抑制optimizer的改写(xx to some JOIN,
etc.)逻辑，强制生成中间临时表。没验证过。
另外，CTE降低了复杂多重子查询的书写难度，更自然，因为可以更多thinking in
prodedure than in set.
【在 B*****g 的大作中提到】
: 这里temp table和view比有什么优势？如果sql结果变化temp table不能显示变化吧。
|
g***l
发帖数: 18555 | 13 CTE就是扔在内存的TEMP TABLE，而且是只读的，没有INDEX一样PEFORM很差，关键还是
JOIN的时候要有INDEX，逻辑要清楚，不产生不必要的中间数据，如果SP中间太复杂，
CTE太多，就要考虑用SUMMARY TABLE，提前用JOB ROLLUP，否则RUN一下要几十分钟，
根本没法用。 |
y****w
发帖数: 3747 | 14 如上面有兄弟说的，cte最重要的用途还是在recursive。如果只是一个扩展易用版的
subquery，就没太大必要了。这也是为什么说oracle以前的cte也就是应付差事，聊胜于无了。 多数情况下，temp table太重量级，不方便，好比拿c去拼java了。
btw，我相信即使在oracle中，recursive CTE也会取代connect by的地位; 新应用的话能少用就少用，connect by早晚deprecated。就好比rbo特色了太久，回头best practice还是大家都用的cbo。
【在 g***l 的大作中提到】
: CTE就是扔在内存的TEMP TABLE，而且是只读的，没有INDEX一样PEFORM很差，关键还是
: JOIN的时候要有INDEX，逻辑要清楚，不产生不必要的中间数据，如果SP中间太复杂，
: CTE太多，就要考虑用SUMMARY TABLE，提前用JOB ROLLUP，否则RUN一下要几十分钟，
: 根本没法用。
|
g***l
发帖数: 18555 | 15 用什么差别不是太大，关键还是逻辑了，碰上个脑子不清楚就为了弄结果赚点钱了事的
，就惨了，你就是把FLOW CHART给他画好，编出来的也还是五花八门。 |
B*****g
发帖数: 34098 | 16 别说干掉connect by，10年后能普及12g就不错了。10年后大家还在care怎么写sql？嘿
嘿。就像俺们头说的，我最多就care12g，再往后我退休了。另外，你确定１０年后还
用rd吗？
胜于无了。 多数情况下，temp table太重量级，不方便，好比拿c去拼java了。
话能少用就少用，connect by早晚deprecated。就好比rbo特色了太久，回头best
practice还是大家都用的cbo。
【在 y****w 的大作中提到】
: 如上面有兄弟说的，cte最重要的用途还是在recursive。如果只是一个扩展易用版的
: subquery，就没太大必要了。这也是为什么说oracle以前的cte也就是应付差事，聊胜于无了。 多数情况下，temp table太重量级，不方便，好比拿c去拼java了。
: btw，我相信即使在oracle中，recursive CTE也会取代connect by的地位; 新应用的话能少用就少用，connect by早晚deprecated。就好比rbo特色了太久，回头best practice还是大家都用的cbo。
|
g***l
发帖数: 18555 | 17 嗯，还是不要强调用什么更好，没有最好只有更好，微软也弄出个什么ENTITY铺在
TABLE上，从NET里读写都很快，也利于开发，估计将来也不用SQL了，谁知道呢。
【在 B*****g 的大作中提到】
: 别说干掉connect by，10年后能普及12g就不错了。10年后大家还在care怎么写sql？嘿
: 嘿。就像俺们头说的，我最多就care12g，再往后我退休了。另外，你确定１０年后还
: 用rd吗？
:
: 胜于无了。 多数情况下，temp table太重量级，不方便，好比拿c去拼java了。
: 话能少用就少用，connect by早晚deprecated。就好比rbo特色了太久，回头best
: practice还是大家都用的cbo。
|
y****w
发帖数: 3747 | 18 你们头儿就是丫死后哪管洪水滔天的角色，呵呵。我要是cto就把丫开掉。
【在 B*****g 的大作中提到】
: 别说干掉connect by，10年后能普及12g就不错了。10年后大家还在care怎么写sql？嘿
: 嘿。就像俺们头说的，我最多就care12g，再往后我退休了。另外，你确定１０年后还
: 用rd吗？
:
: 胜于无了。 多数情况下，temp table太重量级，不方便，好比拿c去拼java了。
: 话能少用就少用，connect by早晚deprecated。就好比rbo特色了太久，回头best
: practice还是大家都用的cbo。
|
y****w
发帖数: 3747 | 19 这个帖子好像说的是具体而微的东西，干嘛扯那么不可预测的将来？呵呵。
好比给20年前的c programmer讲别玩c了研究啥算法优化啥内存啊，以后用java了，内
存便宜的很。。。。。
路还是要一步一步走到。
【在 B*****g 的大作中提到】
: 别说干掉connect by，10年后能普及12g就不错了。10年后大家还在care怎么写sql？嘿
: 嘿。就像俺们头说的，我最多就care12g，再往后我退休了。另外，你确定１０年后还
: 用rd吗？
:
: 胜于无了。 多数情况下，temp table太重量级，不方便，好比拿c去拼java了。
: 话能少用就少用，connect by早晚deprecated。就好比rbo特色了太久，回头best
: practice还是大家都用的cbo。
|
B*****g
发帖数: 34098 | 20 俺们公司的CTO最恨搞新技术革新的，hoho
？嘿
后还
【在 y****w 的大作中提到】
: 你们头儿就是丫死后哪管洪水滔天的角色，呵呵。我要是cto就把丫开掉。
|
|
|
n*w
发帖数: 3393 | 21 sql server 上的非递归cte应该和subquery更接近吧。如果不是等同。
和temp table应该完全不同。 |
b****t
发帖数: 112 | 22 SQL Server 可以对 sp 加密，但好像也可以破解。
http://searchsqlserver.techtarget.com/tip/Decrypt-encrypted-sto
deliver给客户呢，怎么保护ip就是一个大问题，比如你辛辛苦苦搞一套db监控软件，
不注意保护的话人家好点的dba轻轻松松把你的sql都给抠出来了。
【在 y****w 的大作中提到】
: 这个帖子好像说的是具体而微的东西，干嘛扯那么不可预测的将来？呵呵。
: 好比给20年前的c programmer讲别玩c了研究啥算法优化啥内存啊，以后用java了，内
: 存便宜的很。。。。。
: 路还是要一步一步走到。
|
y****w
发帖数: 3747 | 23 sql server的sp有encyption选项。oracle好像可以用什么wrapper. 静态的加密都有破解的可能。
再说总是有办法收集动态运行的sql的（即使是静态sql），这些放到库里去，就不保险。
【在 b****t 的大作中提到】
: SQL Server 可以对 sp 加密，但好像也可以破解。
: http://searchsqlserver.techtarget.com/tip/Decrypt-encrypted-sto
:
: deliver给客户呢，怎么保护ip就是一个大问题，比如你辛辛苦苦搞一套db监控软件，
: 不注意保护的话人家好点的dba轻轻松松把你的sql都给抠出来了。
|
a9
发帖数: 21638 | 24 直接用c写external sp也行吧。
【在 b****t 的大作中提到】
: SQL Server 可以对 sp 加密，但好像也可以破解。
: http://searchsqlserver.techtarget.com/tip/Decrypt-encrypted-sto
:
: deliver给客户呢，怎么保护ip就是一个大问题，比如你辛辛苦苦搞一套db监控软件，
: 不注意保护的话人家好点的dba轻轻松松把你的sql都给抠出来了。
|
Z*****l
发帖数: 14069 | 25 cte是啥？就是with带一坨那种？
【在 y****w 的大作中提到】
: 滥用CTE,把整个过程逻辑都一层层放到cte里面了。连最普通的源表上project逻辑都要
: 用一层cte包起来。我数了数大概一个sql语句用了30-40层。
: 那一块不重要，性能好十倍差十倍也没关系，边边角角，不然肯定打回去让他重写了。
: 我都怀疑是不是老印们都一个培训班毕业的，好几个都这个风格。估计都是当初被填鸭
: 了，面试的时候可以振振有词的讲：1)精通cte 2) 1-sql solution. 听起来还是蛮牛
: 的。
|
B*****g
发帖数: 34098 | 26 did not try yet
http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Finnig
破解的可能。
险。
【在 y****w 的大作中提到】
: sql server的sp有encyption选项。oracle好像可以用什么wrapper. 静态的加密都有破解的可能。
: 再说总是有办法收集动态运行的sql的（即使是静态sql），这些放到库里去，就不保险。
|
B*****g
发帖数: 34098 | 27 c能加密吗？
【在 a9 的大作中提到】
: 直接用c写external sp也行吧。
|
B*****g
发帖数: 34098 | 28 对
【在 Z*****l 的大作中提到】
: cte是啥？就是with带一坨那种？
|
y****w
发帖数: 3747 | 29 在编程语言中对核心逻辑加密，数据方面只取源数据，核心逻辑得放到自己这边来，不
能扔到数据库去跑。
【在 B*****g 的大作中提到】
: c能加密吗？
|
B*****g
发帖数: 34098 | 30 你给客户做啥都得给人家。
【在 y****w 的大作中提到】
: 在编程语言中对核心逻辑加密，数据方面只取源数据，核心逻辑得放到自己这边来，不
: 能扔到数据库去跑。
|
|
|
y****w
发帖数: 3747 | 31 ok,suppose what you're working at is Quest Spotlight.
【在 B*****g 的大作中提到】
: 你给客户做啥都得给人家。
|
B*****g
发帖数: 34098 | 32 That is why "We should not provide software, we should provide service!"
That is how oracle/ibm successed but sun failed.
【在 y****w 的大作中提到】
: ok,suppose what you're working at is Quest Spotlight.
|
y****w
发帖数: 3747 | 33 open source出有用的东西，容易出名，但容易被ｃｏｐｙ，回头自己活活饿死，看着
别人大口吃肉自己连口汤都没有。尤其是核心ｖａｌｕｅ容易被ｃｏｐｙ的冬冬。
【在 B*****g 的大作中提到】
: That is why "We should not provide software, we should provide service!"
: That is how oracle/ibm successed but sun failed.
|
s**********0
发帖数: 266 | 34 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掌握着加密和解密的原理。
破解的可能。
险。
【在 y****w 的大作中提到】
: sql server的sp有encyption选项。oracle好像可以用什么wrapper. 静态的加密都有破解的可能。
: 再说总是有办法收集动态运行的sql的（即使是静态sql），这些放到库里去，就不保险。
|
a9
发帖数: 21638 | 35 clr解密也忒容易了。
code
DBA
sql
理。
【在 s**********0 的大作中提到】
: 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掌握着加密和解密的原理。
:
: 破解的可能。
: 险。
|
B*****g
发帖数: 34098 | 36 点net写的dll解密很难吗？赫赫
code
DBA
sql
理。
【在 s**********0 的大作中提到】
: 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掌握着加密和解密的原理。
:
: 破解的可能。
: 险。
|
s**********0
发帖数: 266 | 37 是不难，但估计一般的DBA也没兴趣去破解。总比直接给DBA create procedure XXX
with encryption 的sql script要安全吧。
其实最后建完的stored procedure， DBA和developer大家都有execute的rights；要偷
些信用卡号码对大家来说都不难。 所以我也不知道公司（和PCI的要求）为什么要这样
搞。。。 可能也就是防防一般人进入network把整个database backup file给偷了?
【在 B*****g 的大作中提到】
: 点net写的dll解密很难吗？赫赫
:
: code
: DBA
: sql
: 理。
|
l******t
发帖数: 660 | 38 知道解谜的原理有什么用， 那些加密的算法都是公开的， 但是你知道算法也解不了啊
【在 a9 的大作中提到】
: clr解密也忒容易了。
:
: code
: DBA
: sql
: 理。
|
y****w
发帖数: 3747 | 39 一般的dba可能没兴趣，但假如我是他的竞争对手那就有兴趣了。
了?
【在 s**********0 的大作中提到】
: 是不难，但估计一般的DBA也没兴趣去破解。总比直接给DBA create procedure XXX
: with encryption 的sql script要安全吧。
: 其实最后建完的stored procedure， DBA和developer大家都有execute的rights；要偷
: 些信用卡号码对大家来说都不难。 所以我也不知道公司（和PCI的要求）为什么要这样
: 搞。。。 可能也就是防防一般人进入network把整个database backup file给偷了?
|
B*****g
发帖数: 34098 | 40 你这个超过architect level了
【在 y****w 的大作中提到】
: 一般的dba可能没兴趣，但假如我是他的竞争对手那就有兴趣了。
:
: 了?
|
|
|
y****w
发帖数: 3747 | 41 产品的architect呢。 than project architect.
【在 B*****g 的大作中提到】
: 你这个超过architect level了
|
s**********0
发帖数: 266 | 42 说到解密我倒想起一件事，我们单位有一个DBA差点被fire。 他在一个sql server上竟然有差不多一年没有backup 我们用来加密的 certificates 和 symmetric keys （每过一段时间要重建的）
查出来之后被骂的狗血喷头，还好server没出事，不然的话我们最重要的数据全都变
成了一堆garbage data. 公司历史上也出过一次这样的事，有一个新的project
deploy to production后我们发觉谁都不能还原OLTP server上加了密的数据 （一帮人大眼瞪小眼，谁也没办法）。 还好2天不到就发现了， 结果只能去重听所有的recording，一个一个再把所有的数据manually update回去。 噩梦啊。。 |
y****w
发帖数: 3747 | 43 dba也是高风险职业，有两起血案，圈子里挂上号就不好过了，磕磕。
2
【在 s**********0 的大作中提到】
: 说到解密我倒想起一件事，我们单位有一个DBA差点被fire。 他在一个sql server上竟然有差不多一年没有backup 我们用来加密的 certificates 和 symmetric keys （每过一段时间要重建的）
: 查出来之后被骂的狗血喷头，还好server没出事，不然的话我们最重要的数据全都变
: 成了一堆garbage data. 公司历史上也出过一次这样的事，有一个新的project
: deploy to production后我们发觉谁都不能还原OLTP server上加了密的数据 （一帮人大眼瞪小眼，谁也没办法）。 还好2天不到就发现了， 结果只能去重听所有的recording，一个一个再把所有的数据manually update回去。 噩梦啊。。
|
b****t
发帖数: 112 | 44 Sql Server 不是不推荐用SQLCLR吗?
http://www.sswug.org/articles/viewarticle.aspx?id=22480
code
DBA
sql
理。
【在 s**********0 的大作中提到】
: 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掌握着加密和解密的原理。
:
: 破解的可能。
: 险。
|
n*w
发帖数: 3393 | |
a9
发帖数: 21638 | 46 也不能说不推荐吧。能不用就不用就是了。
ms也是花了力气做上去的，怎么就说不推荐呢。
这
【在 b****t 的大作中提到】
: Sql Server 不是不推荐用SQLCLR吗?
: http://www.sswug.org/articles/viewarticle.aspx?id=22480
:
: code
: DBA
: sql
: 理。
|
