- 主题:求问oracle程序员的梗 出处
程序是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.*
太感谢了。
【 在 eGust 的大作中提到: 】
: 本版搜“oracle程序员的日常生活”
:
--
FROM 183.158.146.*
董事会还懂pg ？很专业嘛。
顺便问问，pg 怎么样，实用靠谱吗？
- 来自 水木社区APP v3.5.5
【 在 eGust 的大作中提到: 】
: 我们现在说是董事会要求换 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。我们公司目前就是这种状态……
--
FROM 203.145.95.*
你这是着火房间，我那是屎山，不动就好了，动了就滑坡。
换PG理论是可以，不过前提是业务停个一年半载，没有新热数据进来，静下心来梳理，
要是像现在这样成天铲屎救火的，哪有可能迁移到PG。
【 在 eGust 的大作中提到: 】
: 我们现在说是董事会要求换 pg，找了个公司给我们做了份评估，据说报价 $370k+，直接把所有东西（包括 store procedures）都转过去。
: 老板目前可能还有些误解，以为花37万就可以了，不知道我们这边配合也需要很长时间，而且可能同时要停止开发新功能，这部分的成本并没有考虑进去。我们的代码目前大概是这种状态：
: ───────────────────────────────────────────────────────────────────────────────
: ...................
--
FROM 125.118.170.*
case不一样的，他们这种新生代应用是一回事，
像我这样医院传统关系数据库应用，不写join我都瘆得慌。
【 在 littelShrimp 的大作中提到: 】
: 数据库还写什么程序？
: 我记得以前参加过一个项目，那个总设说现在数据库都不写代码了，尽量不写sql，尤其不写多表联合查询。
--
FROM 125.118.170.*
同问，
1.pg国内支持力量怎么样，Oracle的维保一大把，就像青藏线上能修丰田的汽修店一样烂大街，半夜三点都能找到人擦屁股。
2.pg调试存储过程之类的方便么，Oracle的调试，呵呵哒。
【 在 fanci 的大作中提到: 】
: 董事会还懂pg ？很专业嘛。
: 顺便问问，pg 怎么样，实用靠谱吗？
: - 来自 水木社区APP v3.5.5
: ...................
--
FROM 125.118.170.*
董事会懂不懂 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.*
number(2,20)这个坑我也遇到过。。。。。。
【 在 eGust 的大作中提到: 】
: 董事会懂不懂 pg 我不知道，但要求替换掉 oracle 是投资者的要求。总之就是，不管是投资人、aws（什么战略伙伴之类的）、还是客户，都要求老板干掉 oracle
: 具体不知道，但目前有几个使用场景我是非常高兴的。原生支持 uuid、json 类型，而且基于 json 做 query 也非常简单。我们 oracle 有一个 column 的定义是 NUMBER(2,20)，我也不知道 oracle 到底怎么处理的总之是定义出来了，我全局替换 NUMBER 放 pg 里一跑，挂了，然后才注
: 獾骄尤挥姓饷锤鐾嬉舛
: ...................
--
FROM 183.6.114.*
居然不提最著名的坑
'' is null
''=''
【 在 eGust 的大作中提到: 】
: 董事会懂不懂 pg 我不知道，但要求替换掉 oracle 是投资者的要求。总之就是，不管是投资人、aws（什么战略伙伴之类的）、还是客户，都要求老板干掉 oracle
: 具体不知道，但目前有几个使用场景我是非常高兴的。原生支持 uuid、json 类型，而且基于 json 做 query 也非常简单。我们 oracle 有一个 column 的定义是 NUMBER(2,20)，我也不知道 oracle 到底怎么处理的总之是定义出来了，我全局替换 NUMBER 放 pg 里一跑，挂了，然后才注
: 獾骄尤挥姓饷锤鐾嬉舛
: ...................
--
FROM 183.6.114.*