@terrysnake #3 音响有耳机插孔但是不能用麦克风😐

@WashFreshFresh #3
@tianwaifeixian #4
@ljtfdt #5
@wu00 #7
@Habyss #8
最新发现,服务做了集群连接同一个 redis,当查询/插入都在同一台服务器时没有问题,不同服务器时就查询不到了

redis 配置都是一样的

@tianwaifeixian #4 异步的,所以才通过缓存读数据
@ljtfdt #5 图形化界面已经查出数据了,但是 A 还是一直获取 null

@WashFreshFresh #1 没集群

@skywalkerfc #72 拍立得

@win301 #11
b ，c 是 a 的扩充字段不会关联其他表，但 a 可能会继续关联新的 d ，e 表

@DreamSpace #9
我就用优惠券举个例子吧
表 a 是通用的优惠券表，包含优惠金额，有效期限等
表 b ，c 是特殊的优惠券表，像某些券会指定哪些商家可以用，就会拓展一些可用商家 id 的字段

a ，b ，c 本质都是优惠券，只不过 a 没有额外字段的需求，能满足大部分优惠券的场景，b ，c 是为了剩下一小部分的场景做了单独的处理。
b ，c 显式地继承了 a ，也可以认为 a 继承了 a 本身，a 不仅是一个实体，也作为了一层抽象。

优惠券新增方法的参数声明可以声明成 a ，这样传参也能传入 b ，c 的实体类，之后就可以根据实际类型去处理不同的业务

直接复制父类的属性贴在子类上然后打注解也许更快。 --- 如果没有更好的方法了我是准备这么做了

@win301 #5
我只是在这基础上多了继承关系,这样在增删改查的时候可以少一步拆分或组装实体类的步骤
至于增删了字段,相比原来的模式也就多了需要改动插入和更新语句

这是我目前的理解,我认为还是利大于弊的

@RedBeanIce #3
目前有 3 张表 a,b,c
a 是主表, b,c 可以看成是 a 表的扩充字段.部分情况下 a 表的字段就够了,部分情况需要用到 b 或者 c 的字段.( b,c 都需要和 a 关联查询,不会查单表)
我想着用同一个实体接收数据的话无用的字段太多,就把 b,c 的实体类继承了 a.
这样就可以直接用 b,c 的实体类接收数据.

我也没啥设计经验,前两天本就想发帖问问的,但尝试做了下之后除了不能使用 mp 默认提供的方法也没发现啥弊端就继续这样做了

@Jrue0011 #1 要自己实现的话就算了,为了一碟醋包一盘饺子😂 实在没办法我就老老实实写 sql 了

@ciki #56 安徽

@banmuyutian #53 所以我也在犹豫中,我看一盒都是益佰块🙃

@pengtdyd #17 一开始就考虑送拍立得,只是过来问问看有没有更合适的礼物😁

@alibababababa #10
@hlhshsh #11

小天才已经有了,我也在考虑送个拍立得

@AoEiuV020JP #9
先收钱还有风险吗？

而且币安还需要实名认证的吗，感觉好麻烦啊😧

有没有可以使用虚拟币交易的平台,想买些礼品卡之类的东西

@AoEiuV020JP #4 场外交易是私下找人交易吗

@rimutuyuan #2 提现周期貌似挺长的,提完工单不知道什么时候会打款,直接交易问题蛮多的

@JamesR 骑驴找马要等对方发 offer 了再提离职吗，我也开始准备面试了，担心提离职后对方不要了。

@coderluan 工资 4k 没提绩效，其实我还好，没怎么扣过绩效，有几个同事基本月月扣，有个同事和我说他入职到现在不知道工资不扣到手有多少钱😂