其实我一直觉得 现在大部分的语言都是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..不知道算不算碰上设备。 : 以上，谢谢各位大大的指点。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 117.19.148.160 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1584547929.A.494.html