其实我一直觉得
现在大部分的语言都是ORM来写的
除非特化场景
不然不太直下SQL
多数用架构来解决效能问题
讲直白点
架构师够力DBA几乎可以省下来
跑起来要时间的都预跑cache起来
善用LRU跟Redis几乎读方面
依赖SQL很少
大概就大量Transaction的比较需要优化
而量大到一个级别也不是靠优化能解决
最终还是靠架构来处理
当然DBA在量大时的优化也不可少
不过相对的重要性似乎被稀释不少
所以要当DBA没有别的
专心当Oracle的就好
其他的DB基本上几乎都靠架构处理
只有用Oracle的公司专心买单给Oracle
软硬直向扩展到爆
做这种的才值钱不过缺也有限
认真说
还是写程式未来的出路广多了
※ 引述《carsun00 (永夜)》之铭言：
: 各位年薪300的大大们好，
: 有幸最近取得OFFER，麻烦提供点意见。
: 背景
: 私立科大的资工系
: 软件业工作经验2年多一点。
: 现职主要技能都在DB上，但是还不到专业DBA，
: 最多是简单的效能、语法结构调整、IO存取。
: 硬件面的完全不会。
: N为现职公司的薪水
: OFFER - 都是博弈
: 公司 A公司 B公司
: 职务 C#程式开发 DBA
: 薪资 N+8 *14 N+11 * 14
: 地点 皆台中
: 工时 09~18弹性30分 09~18
: 内容 主要系统维护 协助产品开发SQL调整
: 副协助客服排除问题 规划系统架构(硬件面)
: 加班 不加班， 平常不加班
: 但有机会ONCALL 产品上线时会需要支援
: 优点 增加写程式能力， 专心于DB上，
: 过往经验都是SQL面。 衔接现有技能
: 缺点 感觉维护性质较高 博弈的DBA，
: 不确定风险会不会比较高。
: 写程式的机会降低。
: 考量点
: 两边给的条件其实都差不多，
: 感觉上唯一的差别在风险&未来规划。
: 未来目标是加入AWS的技能
: 但两间都没机会用上，所以要自己学习。
: [程式+AWS] VS [DBA+AWS]的发展，
: 不太确定谁比较有优势
: A公司单纯在程式的维护与开发没碰上设备、金流的问题。
: B公司定位是DBA..不知道算不算碰上设备。
: 以上，谢谢各位大大的指点。