我知道有很多针对这个问题的问题。尽管有很多好的命名约定建议，但我们的团队中进行了辩论。
一个团队成员坚持我们应该这样命名我们的表：sProducts 和这样的主键：ProductGuid
他的系统中有两个前缀（s，h），所以 s 代表静态和 h - 抱歉，我真的不知道。我可以看到那里绝对没有逻辑。他说每个大型的预言机和 ibm 系统都是这样工作的。我从未使用过 oracle 或 ibm 系统，那么是否有添加 s 和 h 之类的前缀的约定？它们代表什么？
有人在那里，谁也这样做？我很抱歉这个问题 - 但我不想总是添加一个 s 并且不知道为什么......
他说每个大型的预言机和 ibm 系统都是这样工作的。
这是一个相当大胆的声明。很可能他是错的，即使我对数据库一无所知，我也会这么说。（我曾在 800 多家公司担任顾问。我从未见过这种情况。）
用表名编码今天的信念会为明天带来问题。表变成视图，视图变成表，视图变成表值函数，静态表变成，嗯，明天的“h-word”并不罕见。
当静态表格最终成为 h 字时，您将如何处理表格？留下名字吗？现在，每次需要找到该表时，您都必须更加努力地思考。把名字改成h字？现在你已经破坏了所有依赖它是静态的应用程序。更改名称并使用旧名称创建可更新视图？似乎很多工作一开始就可以通过一个好名字来避免。
我对你提出的问题感到困惑。您提到“后缀”，但您显示“前缀”。
这里有很多宗教问题...
我在字段/列/属性的上下文中介绍了这一点。其他种类的东西也需要有一致的形式。
许多命名约定的根源——与命名标准不同——是 IBM 1970 年代的“OF 语言”。
OF 使用 PRIME-MODIFIER-CLASS 格式，为客户帐号生成 CUST-ACCT-NO。
一个好名字希望能完成几项任务……表明它是什么类型的数据（例如日期或文本）以及它对业务的意义。
CLASS 词（后缀，但匈牙利表示法中的前缀）将是今天类似于数据类型的内容的简短列表。日期、文本、代码、标志（今天的二进制）、金额等。
CLASS 单词不应该超过一打或两个。
PRIME/MODIFIER 词将更侧重于系统支持的业务问题。
无论如何……最难的部分是保持一致。
BIG no no 将 CODE 缩写为 CD 和 CDE。
破折号 (-)、下划线 (_)、camelCase 等分隔符问题由技术环境决定，不值得讨论。
在所有这些问题中，最重要的问题是一致性……人类最不擅长的事情。
没有正确的命名约定。如果你的梦想太复杂以至于别人无法理解，那么你就做出了错误的选择。
顺便说一句......命名约定是我们主要处理的......一个模糊的想法，幸运的是，它被写在一本尘土飞扬的，被遗忘的手册中。
命名标准是自动执行的，就像你的编译器一样。
我曾在一个大型系统上工作过，该系统具有出色的命名约定（由 DBA 强制执行）......能够浏览数据元素或段落名称并知道它是最解放的感觉。