@xiaochong0302

我们的是

const LEVELS = [
self::LEVEL_JUNIOR =>'初级',
...
];

不用方法，除非需要逻辑判断的。


当然更理想的其他语言的 enum 类型，就少了一层定义，且可以采用位运算符。
use MyCLabs\Enum\Enum;

class Gender extends Enum
{
public const MALE = '男';
public const FEMALE = '女';
}

表内创建人字段和更新人字段，只存了 name，没有存人的 Id 。当时想着是应该只关心是谁做的操作，所以没有加入 id 的关联关系。但是实际上在表设计中有关联关系但是不存关联信息的数据干脆就不存，要存就都存。

我这里建议假设 post 表，需要保存更新人，那么增加是 post.update_user_id 就行，除非需要经常 “select fields from post where user.fullname like ?”，那么需要加一个 post.update_user_fullname 字段



关联表的索引关系一定要明确，该做约束的约束。该设置必输的设置必输。

数据库设计的时候一定要按最严格的约束去，但是不要嵌套删除之类的。对于可选的字段，用 null 而不是 0 或者''。



部分在代码中或者项目里比较高频的字段，表设计时最好加_info 。

什么鬼？ 有必要吗？ IDE 不会自动提示 field ？
用户名表的用户名是高频字段，所以需要 user.name_info 吗？ XJB 折腾吧！




英文尽量要合理 比如创建人不应该是 create_name 合理的应该是 creator_name，这块当时设计的时候想的是 creator_name，但是为了和创建时间和更新时间对应就统一变成了 create_name 和 lst_name 。

前面已经有答案。created_at, updated_at,create_user_id,ower_id,admin_user_id,create_username,create_user_fullname 需要根据项目和字段实际用途和存储关系来。



架构设计是门艺术，这门艺术的核心是可维护性，开发效率以及运行效率的恰如其分。

难道不是以后不听话方便跪吗？

这是一个适合技术开发者的商业点子！

表名就可以表示自身了，所以没必要加前缀，除非外键 order.user_id 这样的

经销存等等都可以无代码和低代码。

氚云，宜搭，简道云，明道云，SeaTable 。。。

可以说是当前和接下来的风口。


公司一套几十人用的经销存+CRM 就是用的 XX 。

@tachikomachann

同意 #35，

没毛病，房子只是你一人的，写了你一人名字，属于婚前财产，估计房贷还没还完，
如果你要离婚，她确实什么保障都没有啊。

首先恭喜，好好锻炼下，下次找工作就是小组长负责人起了。

团队管理最重要就一点：人们追随你时因为爱戴你。

@shiny

etf 反向对了怎么亏钱？求教？

我还以为保持年轻的秘诀就是不要笑，因为： 皱纹 --- 是你笑过的痕迹。

结果，段位差了太多。。。

买一个小主机，自动同步到云端。

“欢迎使用小米自动驾驶系统，系统正在启动！”
广告播放 60 秒钟后，
“系统已启动，正在等待下一个绿灯“。

35 之后收入下降 ？
不成立。

所以现在能买就买呗，一线大跌概率很少。


当年我就是深圳 2W 没买，买了长沙 7K 的，现在回长沙几年了压力没深圳大，也不用三点一线做社畜，但是总资产相对就少了几倍吧。

没办法，靠工单收费保持增长了。

通常来说就是调用静态方法创建实例，然后调用实例的方法来修改、摧毁自身。

选择这样：

canvas= new canvas();
duck=new duck();
duck.setColor(red);
duck.run(speed);
duck.eat();
duck.die();
cavas.add(duck);


而不是这样：

canvas= new canvas();
duck=new duck();
addDuckToCanvas(duck,canvas);

更不要：

moveDuck(canvas,duck,speed)


为什么？因为实际情况可能是：

canvas= new canvas();
duck=new duck(color,speed,size,direction);
canvas.add(duck);

这是鸭子的运动由自己控制，而不是画布控制。

就如现实世界：

交警根据司机是否违规开罚单，司机自己管开车。

每个类做好自己的事情情况下，尽量减少外部条件依赖。

外部依赖越少，代码越好维护。

赞同 @GM

修改内部属性和数据的通常都不用静态。
可能连接池后者单例的都不用静态。


案例一：

比如 redis 操作，没必要静态。

r = new redis();
r->set();

因为这里 redis 可能是连接池，也可能是单例，这时候为了维护容易，不要再去做 redis::set 方法，因为静态方法可能跳过构造函数。

假设有多个 redis 数据库，那么可以是

r1 = new redis(db1);
r2 = new redis(db2);

静态方法可能就成了

redis::set(key,val,db1)

用起来就纠结了


案例二：

mvc 的 model 里面通常除了 create 方法，都不要静态（静态常量可以有）

Class Product{

const STATE_DRAFT =0
const STATE_PUBLISH =1

public static function create(data){}

public function update(data){}

public function remove(){}
}

这时候 update，remove 不静态，是为了减少对外暴露接口，方便代码统一修改。
create 用静态是因为它返回了 product 实例

其实我觉得没有必要这么麻烦，先塞入队列 1，然后排序加入队列 2，然后取出队列 2 有序文件，发送给打印机。

没必要转 PDF，虽然我知道改 pdf 页面尺寸的一堆方法。

曾经用过快递鸟，也可以。

初略看了下这个组件，不是有模板吗？最多修改或者自定义一个模板就行了吧？