@baijiahei 抄官方的是吧

@QlanQ 没有明知会改这回事，以后出什么需求谁都不知道。冗余数据到某种表，只是挑几个字段，不存在那么多数据问题，而且按你认知，单独冗余出某张表查询效率不高的话，连表查询效率只会更低下。
既然说到连表了，冗余的好处就是只查一张表，你连表的话，查询慢，特别是后台，基本上产品会要你很多字段可以检索，检索字段多的时候，连多表是个灾难，特别是存在模糊检索字段，无法用上索引的时候

@fyxtc 我也很无奈，现在的我，也不是想贴段代码比个高低，争个第一了，没有意义了啊，哎

@QlanQ 不管新旧项目，都离不开发展历史问题，只能说你遇到的项目还不够多吧，有时候某个模块当初的开发者设计的挺好的，但是顶不住需求变更。比如常见的 用户表、用户信息扩展表、供应商用户表、地推员 等等等等，开始是挺独立的业务，但是后来某天产品要求做个列表，产品为了方便，这个列表的展示信息，居然横跨 7 个表，你能选择的无非就是上面讨论的两个方案，要么冗余出来，要么查多表

@rrZ2C 现在好多 4S 店买车不是都号称两年还是三年的无息贷款吗，难道是骗人的？我只知道开头收一个几千块的金融服务费

@buffzty 写的 low 不 low 就随你说了，但是不像你挑别人毛病，自己给出的方案还是 bug ，你用 dechex 把 1000000000000000000000 转化成十六进制给我看看

一直很好啊

讲过去没有用，再回到 5 年前，我会买比特币，最低是 2 万 5 一枚，高的时候涨到 48 万一枚

@ElvY 我现在是代码随意，因为是我自己维护的。文档我倒是挺认真写的，因为我不想坑前端同事

@Rache1 奥，对了，第 1 点 bcdiv 的 18 这个疑问忘记告诉你了，这个是因为数字币 eth 中， 单位 wei 转 eth ，存在小数，精度需要保存到小数点后 18 位

适量的冗余是正常的，有时候是为了查询方便，而且对于没有要求前后数据变更强一致性的数据，也无需花精力去同步。
比如之前我做过一个客服聊天记录表，我就在里面冗余了用户昵称，方便查询，用户改昵称，我也不会同步过来的，已经问过产品，说无所谓

@Rache1 兄弟，有些代码，离开业务场景空想是想不明白的，这个代码我四五年前写的了，模糊记得一些，你疑问的点大概和你说下吧：
1 、1000000000000000000 和 0x 是业务需要，它是不会也不可能变化的，所以我写死了专用值，也不存在我需要添加除 0x 前缀外的场景，这个是专用于数字币计算的。
2 、我不知道你所说的 PHP 自带的的十进制和十六进制转化是否指的是 dechex 这个函数，如果是的话，这个函数是用不了的，数字币都是高精度计算，数字位数是 n + 18 位，用自带函数计算是超出上限的。
3 、我直接拼 0x 是因为我很确定我上一步的值是不存在 0x 的，无需重复调用兼容性的方法增加判断，当然，你要说非要调用比较优雅，也不是不行，这个见仁见智，我不反驳，我当年怎么想的，我也记不起来了。
4 、同 1 解释，因为只专注于+0x
5 、此工具函数比较简单，当时为什么没有单独提出来，我已经记不清了。
6 、是的，可能当时忘记了吧。

@xinyewdz 我已经摆烂好多年了

@idealhs 抛开业务场景的话，肯定很难想象啦，这种业务代码要结合业务看才好理解

@eilisonLiang 是啊，我现在的状态，对优雅的态度，总结起来就是：时间太赶算了、能跑就行算了

@NessajCN 这个工具类有具体实用场景的，做数字币的接触多了就知道了，不纠结具体业务了，我只是缅怀以前对代码的激情，当年水平有限，以现在的眼光去看，可能几年前刚入行写的代码，是有瑕疵的，但是当时我是用心去写的

@kingpo 朱村的我也在关注，想找近地铁口的