@QlanQ 所以说你还是绕回去了连表的问题啦，而且后台查询很灵活的，你预测不到使用者会用到哪些检索条件，你当然可以写一堆判断来动态组合缓解一些压力，但最终也避免不了有连表的情况，这个表设计模式，问题就在于这里

之前有个同事回长沙老家上班了，代价就是要有降薪的觉悟。还有他是之前回去的，现在有没有岗位我就不知道了。
另外问下楼主，贷款买房，没还清贷款，也能卖吗？是亏本卖吗

如果你有很多钱，问我们也没有用，如果你只是 100 万以下，那我是建议你鸡蛋分篮子装，现在微信、支付宝、银行，都有类似这样的活期 固收+产品，给的利息差不了多少，不要舍不得那百分之 0.0 几的差价。每个地方放个 5-10 万的，风险就很小了

@smirkcat 嗯，写链的话，是 go java c c++比较多，区块链里 php 的话一般是处理业务层的东西

楼主，为什么我和你是反过来的啊，我有一次把我的显示屏调高，仰视，结果颈椎痛了我几天，后面我调低了，稍微俯视看，就不会不舒服了

@Bazingal 不需要给你学习，你比我厉害

@QlanQ 单独用 in 有检索查不了吧，举个例子，要查 abc 三个表，abc 三表都有检索条件，并且要分页和排序，怎么查？

@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 、是的，可能当时忘记了吧。