H******7
发帖数: 1728 | 1 后端码农到底要不要会手写复杂SQL 简单的还行 复杂的写不来 需要补课么
★ 发自iPhone App: ChineseWeb 8.7 |
I*******g
发帖数: 7600 | 2 当然要， innerjoin， outerjoin, natural join, decompose table, write driver
for ODBC, JDBC, etc.
【在 H******7 的大作中提到】
: 后端码农到底要不要会手写复杂SQL 简单的还行 复杂的写不来 需要补课么
: ★ 发自iPhone App: ChineseWeb 8.7
|
d********i
发帖数: 582 | 3 看来我还是辞职算了
driver
【在 I*******g 的大作中提到】
: 当然要， innerjoin， outerjoin, natural join, decompose table, write driver
: for ODBC, JDBC, etc.
|
s****s
发帖数: 345 | 4 还有cross join, explode, haha
driver
【在 I*******g 的大作中提到】
: 当然要， innerjoin， outerjoin, natural join, decompose table, write driver
: for ODBC, JDBC, etc.
|
a*****u
发帖数: 1712 | 5 不用，现在稍微大点网站都sharded数据库，写什么复杂sql。复杂query都hive解决
后端码农到底要不要会手写复杂SQL
【在 H******7 的大作中提到】
: 后端码农到底要不要会手写复杂SQL 简单的还行 复杂的写不来 需要补课么
: ★ 发自iPhone App: ChineseWeb 8.7
|
s****s
发帖数: 345 | 6 傻了 hive能用再后端马 hive run以下要几分钟几小时
hive难道不是SQL写的马？
【在 a*****u 的大作中提到】
: 不用，现在稍微大点网站都sharded数据库，写什么复杂sql。复杂query都hive解决
:
: 后端码农到底要不要会手写复杂SQL
|
g*****g
发帖数: 34805 | 7 不用太复杂，但什么join, group by, exists，不熟悉debug有难度呀。 |
g*****g
发帖数: 34805 | 8 不用太复杂，但什么join, group by, exists，不熟悉debug有难度呀。 |
w**z
发帖数: 8232 | 9 我们全是stored procedure.
【在 g*****g 的大作中提到】
: 不用太复杂，但什么join, group by, exists，不熟悉debug有难度呀。
|
w****r
发帖数: 15252 | |
|
|
g*****g
发帖数: 34805 | 11 你们这个太夸张了，10年前就out了。
【在 w**z 的大作中提到】
: 我们全是stored procedure.
|
r******d
发帖数: 308 | 12 觉得基本的sql语句2天左右就看完了吧。 后端的db还是比较重要吧。 |
L***s
发帖数: 1148 | 13 面FB那次，乱七八糟的什么pivoting也要考 |
c****f
发帖数: 1102 | 14 直接ORM不得了 自从用了ORM join难度以上的语句全忘记了。。 |
g*****g
发帖数: 34805 | 15 会碰到很多 debugging的时候，你不可能找个东西还 ORM.
【在 c****f 的大作中提到】
: 直接ORM不得了 自从用了ORM join难度以上的语句全忘记了。。
|
s******7
发帖数: 1758 | 16 现在的app server跑memcache 不就是用来干这个的，我现在join都用的少了，什么都
是一次性读出来cache, 再automation更新。敏感交易数据才会join来join去的，一堆
constraint. |
p*****2
发帖数: 21240 | 17 现在很多nosql
【在 H******7 的大作中提到】
: 后端码农到底要不要会手写复杂SQL 简单的还行 复杂的写不来 需要补课么
: ★ 发自iPhone App: ChineseWeb 8.7
|
w**z
发帖数: 8232 | 18 你们用orm?还是直接写SQL?
【在 g*****g 的大作中提到】
: 你们这个太夸张了，10年前就out了。
|
w****r
发帖数: 15252 | 19 不会ORM
【在 w**z 的大作中提到】
: 你们用orm?还是直接写SQL?
|
w**z
发帖数: 8232 | 20 我也不用，嫌麻烦。都自己写Dao.
【在 w****r 的大作中提到】
: 不会ORM
|
|
|
w****r
发帖数: 15252 | 21 DAO也不用，现在简单到store procuder直接返回一个table就完了
【在 w**z 的大作中提到】
: 我也不用，嫌麻烦。都自己写Dao.
|
g*****g
发帖数: 34805 | 22 当然用ORM，关系一复杂，手写SQL得累死。这个事情10年前就是共识了。这年头RDBMS/
NoSQL混着用，非常追求性能的SQL query也少了，denormalization的需要也降低了，
ORM就更好使了。Spring Data几乎把所有的boiler plate都去掉了。
【在 w**z 的大作中提到】
: 你们用orm?还是直接写SQL?
|
w**z
发帖数: 8232 | 23 楼上两位，截然相反啊。orm 就是碰到tricky的case 不好搞。都不知道它run 哪个SQL
RDBMS/
【在 g*****g 的大作中提到】
: 当然用ORM，关系一复杂，手写SQL得累死。这个事情10年前就是共识了。这年头RDBMS/
: NoSQL混着用，非常追求性能的SQL query也少了，denormalization的需要也降低了，
: ORM就更好使了。Spring Data几乎把所有的boiler plate都去掉了。
|
g*****g
发帖数: 34805 | 24 tricky的你跑native SQL没啥呀。缺省还是ORM简单。至于SP，不利于Scale, 不cache
friendly，不好维护. 除非是后台生成报表，否则没人用了。
SQL
【在 w**z 的大作中提到】
: 楼上两位，截然相反啊。orm 就是碰到tricky的case 不好搞。都不知道它run 哪个SQL
:
: RDBMS/
|
w**z
发帖数: 8232 | 25 具体说说为什么不scale 和 cache friendly？ sp 在db 上跑，不用把data传回client
再process,应该更快，也省bandwidth. 坏处是增加了db server 的负担，确实不好
debug 和 维护，也没法移植。
cache
【在 g*****g 的大作中提到】
: tricky的你跑native SQL没啥呀。缺省还是ORM简单。至于SP，不利于Scale, 不cache
: friendly，不好维护. 除非是后台生成报表，否则没人用了。
:
: SQL
|
