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

[Renco]

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

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

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

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

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

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

[Renco]

有没有朋友分享点 常见的数据库设计的问题

[puzzle9]

站在全局的角度和第三者的角度 考虑下这个设计
如果是多人开发 一个人先出一版 然后一起讨论下 可通常这个都是架构师处理的
如果是自己开发 等多来几次就可以了

[leonme]

这块有啥靠谱的书推荐吗？同苦恼

[hahasong]

你说的这些都不是问题，只能说喷你的人洁癖太严重了。真要抠起来还得细分，你的 create_time 是什么类型呢，datetime 还是 timestamp 。那对应的要叫 create_datetime, create_timestamp

[wangkun025]

lst_name 也费脑。

[raaaaaar]

我只在数据库概论里读过一章数据库设计的，其他的也求下，实战类的

[lyz1990]

时间的话我是倾向于 created_at, updated_at

[Renco]

@hahasong 确实是有点的，他说受不了这种哈哈哈

[xuanbg]

1 、保持 sql 脚本风格的统一，对齐属性以便阅读
2 、相同字段使用相同的名称、类型和说明
3 、字段保持有序，不要 A 表 a 字段在前 b 字段在后而 B 表则 b 字段在前 a 字段在后
4 、适当冗余，譬如在保存客户 ID 的时候也保存客户名称，减少联表查询
5 、建表的同时规划好索引
6 、使用合适的字段类型，但不必过度考虑存储空间

[pckillers]

这个 lst_name，第一眼看成数字 1 然后读成了 first name 。 然后定睛一看貌似是个小写 l 然后读成 last name 。 然后纠结了 10 秒到底是哪个。。。 LZ 真是起名专家

[soulzz]

你这个问题很好解决 上 mongodb
加字段完事

[ParfoisMeng]

害……很少有人嫌弃字段命名过长，被嫌弃的只有词不达意

[shyrock]

第一点感觉没有改到点上。
数据关联的时候，真正关联的其实是 id 字段，其他如 name 等等都是可以连接查询到的。
所以，必须在主表记录的是 id，是否存 name 看你对性能和存储空间的要求来取舍。

你只记名字，遇到重名的人就完蛋。

[qW7bo2FbzbC0]

你说的这几条，除了第一条在某种严格环境下必须外，其他都是你们团队代码风格的事情

[admol]

其他几个硬要那么理解也可以说得通，比较高频的字段表设计时最好加_info 是什么目的？

[Renco]

@pckillers hhhh 因为定义的 更新时间是 lst_date_time，我为了对应上就智障的写下了 lst_name

[Renco]

@shyrock 是的，表有关联关系一定要用 id，name 这种只是为了减少联表查询做的冗余，其实是可以不要的。没想到这个

[Mithril]

@Renco last 就比 lst 多一个字母吧。。有必要搞这种缩写吗？

[Renco]

@admol 意思是有些字段概念比较高频，比如 operator,property，这种的直接拿来当表名会比较尴尬，所以加一个 info，大概是这个意思，也可能是我没有理解到位

[Renco]

@Mithril 我觉得是没必要的，不过团队一开始统一了 创建时间和更新时间的字段定义，所以就沿用下去了