数据库设计太拉跨被喷了。

[Renco]

发现都是些智障问题，总结一下。

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

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

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

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

目前统计下来应该都是类似的问题。我数据库设计确实拉跨，可能是因为之前做的东西过度松散，对于数据库设计基本都是能用就行，关联表的约束关系可能都没有做全，全靠代码来做。还有很多细节上的问题。其实每次开发都是很快很简单，但是表设计真的让我头大。

[PolarBears]

@kylix 我现在在的单位有套古老的系统就是这样,而且还有些是全拼有些是首字母简写,也没有文档根本猜不透.我真希望如果实在不会取名的话直接用中文做字段名不就挺好的吗

[mingl0280]

这不是 SQL 101 那种级别的知识么，随便找一本数据库设计的教科书都告诉你数据库设计三级范式有啥要求照着做就行了，自己瞎猜结果猜了半天是别人教科书就写过的没意思的好么……

[risky]

created_at
updated_at
created_by

[nutting]

我们公司有规范，还得考试学习

[encro]

表内创建人字段和更新人字段，只存了 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 需要根据项目和字段实际用途和存储关系来。



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

[sockball07]

redis 键名可以缩 数据库可真别缩写

[encro]

@xiaochong0302

我们的是

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

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


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

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

[qile1]

学习啦，我们好多接口都是拼音首字母，那理解起来才酸爽，每次猜字段都骂娘

[Senorsen]

尽量不要反太多范式吧，冗余多了到时不一致问题一多很恶心。

命名尽量规范。

[clf]

尽量不要在其它数据里冗余更多的非 ID 信息，比如不要在业务表里存用户表的姓名字段，而应该存 ID 。因为两份数据后会导致后期的更新维护成本过高。业务表只放业务数据。

[adocder]

别的不说，就第一个存 name 不存 id 的问题，改名了咋整，你跟谁对去