- 主题:求问oracle程序员的梗 出处
本版搜“oracle程序员的日常生活”
【 在 saynothing 的大作中提到: 】
: rt~
: 大概讲述一个oracle程序员的日常工作，改了几天代码，跑测试跑两三个月，提交功能。
: 主要是：
: ...................
--
FROM 203.184.25.*
古时候不知道，现在的话……没有 auto increament int，没有 bool。想跑 docker 连官方的 image 都没有，至少 3G RAM 才能跑，连用户都没建就得占 5G+ 的空间不说，还得等半分钟服务才能起来。这些恶心的地方不说，人家还老惦记着想办法告你，这得有多想不开才用 oracle？
【 在 KEILLY 的大作中提到: 】
: 15～20年前是不是流行使用盗版oracle？
: 然后无一例外被oracle发律师函了…
: 大家倒向mysql…
: ...................
--
FROM 222.153.154.*
我们现在说是董事会要求换 pg，找了个公司给我们做了份评估，据说报价 $370k+，直接把所有东西（包括 store procedures）都转过去。
老板目前可能还有些误解，以为花37万就可以了，不知道我们这边配合也需要很长时间，而且可能同时要停止开发新功能，这部分的成本并没有考虑进去。我们的代码目前大概是这种状态：
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
SQL 2834 299772 18569 52526 228677 6403
Ruby 1832 152747 20686 27997 104064 7543
HAML 1185 25919 1940 586 23393 0
HTML 330 502823 314 3579 498930 0
Ruby HTML 322 5183 632 272 4279 463
Sass 202 41784 1087 6067 34630 0
JavaScript 192 75053 6686 6880 61487 7825
TypeScript 96 11617 1398 500 9719 1354
Vue 90 10573 1269 60 9244 351
有一个7k+行的巨无霸 procedure，里面是核心业务逻辑。一直以来维护它的人，因为一些家里的事情，这个月刚刚退休了。
有一张梗图，一只狗在着火的房间里，一边喝着咖啡，一边说 this is fine。我们公司目前就是这种状态……
【 在 vmx 的大作中提到: 】
: 你要是用了20年Oracle你也换不掉啊，我现在很多代码都是服务器端的PLSQL
: p.s.
: 这整套系统，就像那种末世电影里的违建，好比未来水世界那种电影里的棚子，
: ...................
--
修改:eGust FROM 203.184.25.*
FROM 203.184.25.*
程序是90年代就基于 oracle 写的，核心业务逻辑的确都在数据库里，而且新功能也经常不得不通过更新 stored procedures 进行。我17年加入这里的时候，最大的 procedure 还不到5k行，现在过7k了
【 在 KEILLY 的大作中提到: 】
: SQL 30万行啊，这是所有的计算都让数据库来执行啊？
--
修改:eGust FROM 203.184.25.*
FROM 203.184.25.*
按每行1刀算么
【 在 canper 的大作中提到: 】
: 37万刀确实不贵
--
FROM 203.184.25.*
董事会懂不懂 pg 我不知道，但要求替换掉 oracle 是投资者的要求。总之就是，不管是投资人、aws（什么战略伙伴之类的）、还是客户，都要求老板干掉 oracle
具体不知道，但目前有几个使用场景我是非常高兴的。原生支持 uuid、json 类型，而且基于 json 做 query 也非常简单。我们 oracle 有一个 column 的定义是 NUMBER(2,20)，我也不知道 oracle 到底怎么处理的总之是定义出来了，我全局替换 NUMBER 放 pg 里一跑，挂了，然后才注意到居然有这么个玩意儿。
除了前面说的 auto-inc int/bool 外，oracle 还有很多奇葩限制。比如经常用来表示字符串的 VARCHAR2 最长只能 4000 bytes，再长就只能 clob 了。12c 之前 identifier 有个不能超过30的长度限制，12开始好像是改成128了。因为我们公司的产品是90年代开发的，所以用的 encoding 是 NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252，纯英文。现在开发人员用的 oracle vm 还是 v11，aws 上的客户已经全部 19c + utf8 了，但我们有个哥们儿就爱拿这些说事儿，不能超过30字节，非英文字符要提前干掉再存数据库。
oracle 的 client 也很有意思，似乎对 timestamp with timezone 的转换是在 client 进行的。遇到的最奇葩的一个 bug，就是一个太平洋岛国客户，server 版本和 client 版本的最小版本号不一致。其中一个岛使用俄罗斯的一个时区，刚好在那两个小版本号之间，俄罗斯的那个时区挪了一个小时。于是那个 schema 里所有的 timestamp 都差一个小时，找了好久才搞明白为啥。
总之 oracle 是越用越惊喜，你永远不知道什么时候，它会用怎样的姿势在背后给你一刀
【 在 fanci 的大作中提到: 】
: 董事会还懂pg ？很专业嘛。
: 顺便问问，pg 怎么样，实用靠谱吗？
: - 来自 水木社区APP v3.5.5
: ...................
--
FROM 203.184.25.*
这个我还真不确定别家怎么处理的，不过空的 VARCHAR2 就是 null，我个人还真没栽在这上面过……
说到这个，我们还有几个 column 的定义是不能为 null，但是 default null。我也不知道别的 sql 是怎么处理这种定义的，反正 oracle 里能建出这个定义来
【 在 canper 的大作中提到: 】
: 居然不提最著名的坑
: '' is null
: ''=''
: ...................
--
FROM 222.153.154.*
感觉老产品都差不多，我们这也是天天救火。完全没有测试，stored procedures 更是没人知道怎么测。前几个礼拜就是，有个问题搞不清是 ruby 还是 plsql 的锅，于是下班前被人叫住一起去开会。单独跑报错的 plsql 就不报错，从一个 package 里面跑它就报错。我就只能猜，package 里会创建新 rows，然后那个 procedure 就会报错然后 rollback，所以也不知道到底出问题的 record 到底长啥样。
好在我们这是不需要一定要解决完问才让走的，负责 plsql 的同事觉得有道理，说他第二天再看。后来听说，第二天另外一个同事看了一下，有一个 flag 没设对，试了一下就直接搞好了。这东西既没有文档也没有测试，不知道咋回事儿的话，那就只能浪费时间调试了
现在就是转 pg 也是问题一堆，对方说我转完了，绝对没问题。我们这都没法验证，转换完的代码到底有没有问题。
【 在 vmx 的大作中提到: 】
: 你这是着火房间，我那是屎山，不动就好了，动了就滑坡。
: 换PG理论是可以，不过前提是业务停个一年半载，没有新热数据进来，静下心来梳理，
: 要是像现在这样成天铲屎救火的，哪有可能迁移到PG。
: ...................
--
FROM 222.153.154.*