职场中“油腻”好吗?

职场中“油腻”好吗?

群里一位盆友问“PG里面是不是无脑的使用text/varchar更好, 而不是使用varchar(n)”！

如果你一头扎到问题里去, 肯定马上会被弄到两难的境地, 为什么呢? 因为仔细分析两者都有利弊.

• text/varchar 不限制长度,
  • 如果业务未做限制, 则可能被外部攻击/程序bug导致写入超大字段, 带来性能或其他风险.
  • 如果当前业务只需要32个字符, 但是将来不足时, 不需要在数据库中执行DDL, 只要应用端发布更新就可以了.
  • varchar(n) 限制长度, 利弊正好相反
  • 好处举例: 限制长度后, 避免了外部攻击/程序bug导致写入超大字段的问题
  • 弊端举例: 刚好相反, 如果要修改字段长度, 就要考虑到上面的问题. 1、 数据库中修改字段长度属于DDL操作, 如果涉及逻辑复制, 风险点是不是增加了? 2、即使抛开逻辑复制的风险点, DDL本身也有风险, 例如会不会rewrite table? rewrite index? 大表rewrite风险极大. 3、即使不需要rewrite table, DDL 也是一把大锁, 玩意有其他long query/long xact持有了这个对象的共享锁, DDL也会进入等待队列, 阻塞该对象的其他任意锁请求, 可能导致业务雪崩.

以上仅是简单举例.

本文想要讨论的重点是: 遇到类似的“无解”问题怎么办?

• 1、数据库团队和研发团队一起制定开发规范.
• 2、通过更大老板/技术委员会决议, 让规则生效, 遵循规则行事.

(让更多人参与来制定规则, 也不完全是为了逃避责任, 毕竟一个人的眼界毕竟是有限的!)

这个规范一方面是对双方的约束, 另外也可以保护自己. 虽然规则你可能参与了制定, 但是通过了更大的老板/技术委员会的决议, 责任已经均摊到了更多人头上. 依规则行事的话, 即使出了问题不用你一个人背责任.

职场险恶，很多“老油条”都这么干。

你怎么看？

油腻好吗？如果都这么“油腻”，还会有人愿意有担当吗？欢迎老油条继续出谋划策。

最后祝各位看官朋友国庆中秋双节快乐！