这是一个创建于 1097 天前的主题，其中的信息可能已经有所发展或是发生改变。
以前我在公司一直是基层员工，因拓展新业务需要，上级让我去当组长带团队，角色也开始发生转变，越来越少写代码，更多是做管理和设计。但是每次我把开发设计文档拿出来让大佬们 review 的时候，业务的执行逻辑没多大问题，多数在数据库的设计上被提议。
比如谁是一个信息的结合（ set ），谁是关于这个信息的记录（ log ），数据表直接如何关联才是最合理的。
比如描述一个「是否存在签名」的字段，我用「 exist_signature 」，会上提议用「 has_signature 」或者「 found_signature 」，如何命名才是最合理的。
以前我一直都是执行方，没有站在更高的维度看代码、工程设计，以为这样那样的设计是理所应当。现在成为设计方，才发现在数据库设计略欠经验，特别是接口和数据库字段的命名。一开始我以为抄一下原有的设计即可，但是发现一方面我的业务是新的，不合适，第二方面我还是没有领会为什么要这么设计，为什么要这么命名。
请教下学习数据库设计的正确方式是什么？
比如谁是一个信息的结合（ set ），谁是关于这个信息的记录（ log ），数据表直接如何关联才是最合理的。
比如描述一个「是否存在签名」的字段，我用「 exist_signature 」，会上提议用「 has_signature 」或者「 found_signature 」，如何命名才是最合理的。
以前我一直都是执行方，没有站在更高的维度看代码、工程设计，以为这样那样的设计是理所应当。现在成为设计方，才发现在数据库设计略欠经验，特别是接口和数据库字段的命名。一开始我以为抄一下原有的设计即可，但是发现一方面我的业务是新的，不合适，第二方面我还是没有领会为什么要这么设计，为什么要这么命名。
请教下学习数据库设计的正确方式是什么？
 |
1
anstxy 2021-12-03 11:38:01 +08:00
同问
|
 |
2
zhazi 2021-12-08 19:29:47 +08:00
这个字段的命名 [signature] 比较合适
class Foo { boolean signature; //boolean 类型 boolean hasSignature(){ return signature; } } class Bar { int signature; //int 类型 boolean hasSignature(){ return signature !=0 ; } } 学习数据库设计的正确方式把数据当成数据来看待。不要带入业务信息。业务信息由代码来控制 |
Select Language