encro

首先感谢作者对开源的贡献，
然而比较无法回避，
避免被比较的唯一办法就是胜出。

@wasd6267016
@shmilwdc
@mazyi

本想表达晚上不加班，没想到。。。

你们是对的，我错了，抱歉。

@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，

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