use*_*567 1 oracle database-design
我们正在做一个新的数据库设计，我们预先设置一些规则。我不知道制定这些规则有多大意义，
每个表名和列名都应该有意义。它应该提供有关表或列用途的信息。
表名不应超过 27 个字符，列名不应超过 30 个字符。
表名是复数。例如：COMPANIES, EMPLOYEES, PERSONS, GENDERS, RELIGIONS, COUNTRIES, ...
每个表都有一个主键，table_name_ID即NUMBER(15). 表名在主键列中用作单数。示例：该USER_REQUESTS表的主键为USER_REQUEST_ID。
如果表名或列名超出限制，则使用合适的缩写。示例：CMS_EXEMPTIONS是保留内容管理系统豁免的表。
保留事务数据的表应以_TRANS. 示例：COMPANY_TRANS是保存公司相关交易数据的表。
每个表有 4 个 WHO 列，如下所示：
CREATE_USER NUMBER(15)
CREATE_DATE DATE
MODIFY_USER NUMBER(15)
MODIFY_DATE DATE
作为外键关系的列被命名为被引用表的主键。示例：如果一个表有对该COUNTRIES表的引用，则引用列也被命名COUNTRY_ID为该COUNTRIES表的主键。
如果由于第一条规则（有意义的名称），引用列的含义应该不同于第 8 条规则，则应用有意义的名称规则。例如：COUNTRIES如果它用于保持一个人的国籍而不是命名为 ，那么nationality 和 country 列都与table有关系NATIONALITY_ID。
如果该表有多个与同一个表相关，则它们会被赋予不同的名称，例如BIRTH_COUNTRY_ID，PASSPORT_ISSUE_COUNTRY_ID
如果表是表之间的关系表，则表名包含两个表名。
给有意义的名字一直是我们命名的第一条规则。
这是圣战的东西。没有正确的答案。此外，这些不是可以（轻松）在 CI 工具链中执行的那种“规则”。它们是风格指南。执行将通过代码审查和共识进行，因此请确保所有（或足够多）受影响的人都同意，可以接受这个决定，并可以向下一代和不可避免地会说犯规的不信者证明他们是合理的。
问问自己为什么需要这些规则。对我来说，这是强加的一致性，使代码易于阅读。很快，眼睛就会习惯阅读一种风格，理解力也会提高。当每个查询和表都遵循独特的风格时，每次阅读都从头开始。此外，规则消除了决定对象应该如何命名的认知负担。那个决定已经做出；完毕; 继续重要的事情。无论是对是错，您都不必在这项耗时的低价值活动上再多花一秒钟。最后，一个好的风格可以在结构中揭示和清晰的语义，而不会显得繁琐。
通过这些措施，我认为您的建议很好。
不过，我会提出一些建议。强制每个表都有一个数字代理键可能是不必要的。我已经在这里谈到了这一点。
将约定扩展到查询。选择列表（前导或尾随逗号？）、连接（每行单行或子句？）、子查询、缩进可能有很多变化。团队只需要一次又一次地考虑这个问题。一致的布局有助于明确错误，例如缺少连接条件。
我见过多次使用 WHO 列约定。几乎没用。原创者相对于最近的更新者有什么特殊意义？为什么知道谁在一秒前更新了行而不是谁在三秒前更新了它很重要？
如果我们看到一个包含 FIRST_MAILING_ADDRESS 和 MOST_RECENT_MAILING_ADDRESS 列的 PERSONS 表，作为数据建模者，我们就会有想法。这同样适用于这些 WHO 表格。将它们规范化到它们自己的表中。如果了解特定列的值如何随时间变化很重要，那么这些列也应该在规范化表中。通常这种模式被称为时态表。