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

[Renco]

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

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

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

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

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

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

[Renco]

@xuanbg 了解

[kamal]

本来有收藏数据库设计的文章，但是传送门关站以后，收藏的就是个死链接了……

[Rwing]

@Renco 笑哭，这是哪个智障定的规范

[Renco]

@kamal 可惜，数据库设计一直是我的痛

[nine]

用 Ruby on Rails 的标准规范就行了。
https://ruby-china.github.io/rails-guides/active_record_basics.html

[huifer]

创建人 ID，修改人 ID，创建时间，修改时间，删除标记位（不需要的就不加）常规都加，表字段常用的和非常用的分开设计_core(核心）,_extends （拓展）

[xiaochun41]

库表设计方面的话题太大了，不过基本上可以从这几个方面考虑：
1. 字段命名，
2. 字段类型的选择
3. 数据模型的设计（业务对象如何存，存几张表，如何冗余）
4. 业务对象关联关系的设计（业务对象的关系怎么存等）
5. 索引的设计
6. 存储引擎的选择
7. 库表容量的规划（数据规模多大，增长趋势如何，是否考虑分库分表）
8. 团队的规范
9. 行业最佳实践

暂时想到这些

[young]

数据库中一直有一个建表的模板, id, create_at, create_by, update_at, update_by, delete_at, delete_by, is_deleted
随用随取

[5G]

看下阿里的 mysql 规范文档呗

[QlanQ]

虽然我也比较拉跨，但是我真的 lz 比我还 拉跨
lst_name 我也想到应该是 last_name 但是我不敢肯定，不知道为啥会这样设计，少一个 a 有啥用？
只存 name 不存 id 我也不懂是干啥的，如果有重名怎么办，如果不光需要知道 对方的名字还需要其他的信息怎么办？用中文关联吗？
肯定是先关联 ID 然后在考虑要不要保存 name
约束，很多都说 不要做，特别是外键约束，会影响性能
实在不知道怎么弄好的时候，就 看看 框架默认的是什么，比如 laravel 的框架 时间默认都是 created_at updated_at deleted_at
关联都是 表名单数_id

[ksedz]

先画 ER 图，再生成表

很多时候没有标准答案的，比如你说的存 id 这事，如果要尽量简单无冗余，就只存 id，提高性能简化查询就顺手缓存 name，而一些场景考虑到 name 可能变化甚至删除，你需要知道这里是要修改时的 name 还是最新的 name 。这不是能轻易判断对错的问题，全看对业务需求的理解了。

[Vegetable]

平时多看，自己设计的时候，多换位思考，多反思，每个人都有自己的风格，无可厚非，但是看得多了，就知道什么样的设计是好的，什么样的是差的。

[no1xsyzy]

creation_subject_id
creation_subject_user_name
creation_complete_time

首先，如果是 canonical complete 的关系型表设计，不应当是一个条目里存储创建者
而应当是记录创建的发生，其主体与客体与完成时间（参考是）。
就你提到的设计来说，item.creator_id 实质上是 creation.subject_id ON creation.object_id=item.id 的嵌入，[id] 相消，应当是 creation_subject_id
我认为应当写成 嵌入表名称 "_" 嵌入表字段名
同理，item.creator_name 其实是 user.name ON user.id=item.creation_subject_id 的嵌入，[id] 相消，所以剩下的是 creation_subject_user_name

[Renco]

@QlanQ 是这块设计确实没有过脑子嗨，在反省了

[NULL2020]

1. 关联的字段肯定是用主键 id 啊，一个表的字段除了主键 id，其它都是有可能会变的。

2. 常用的约束一般就是非空和唯一性两个。

3. create_by update_by create_time/create_at update_time/update_at

4. 布尔型的习惯用 xxx_flag，如软删除标记 delete_flag

[no1xsyzy]

完全可以推算出最恰当的组织形式，为什么要自己拍脑袋做转换？

https://gist.github.com/no1xsyzy/5391a79203b0ee64aec7c7de46b028f2

[edk24]

@leonme 阿里 Java 手册

[xhldtc]

阿里的 MySQL 规约可以参考下： https://github.com/alibaba/p3c/tree/master/p3c-gitbook/MySQL%E6%95%B0%E6%8D%AE%E5%BA%93

[buster]

难道只有我一个人，第一版数据设计总是不完善，做着做着就改呗。

[jones2000]

请专业的 DBA 设计， 否则后续肯定还要重新设计。