如何评估数据库系统中表的好坏？

Question

我们如何评估数据库系统中表的好坏？我们需要分析哪些方面？我可以建立一个进行此类评估的模型吗？如果是，那么如何？

Answer 1

非详尽清单。对于所有这些问题，是是一个很好的答案，没有是坏的。

1. 该表是否具有明确的业务功能？它的适用性如何？
2. 这张桌子有名吗？表格列的名称是否很好？业务用户是否理解他们的意思？
3. 表格是否有主键？
4. 表是否对所有业务（候选）密钥都有唯一约束？
5. 是否定义了所有外键？
6. 具有约束值的所有列是否具有引用数据表或检查约束（或MySQL的enum）的外键？
7. 所有列都具有正确（最强）的数据类型吗？
8. 表格是否正确归一化？ （在至少表示Boyce-Codd Normal Form的OLTP环境中，数据仓库中的情况有所不同。）
9. 该表是否包含任何包含＆＃34;智能键＆＃34;，CSV字符串，JSON，XML，其含义取决于另一列（或另一个表）中保存的元数据的不同数据项的列，或任何其他奇特的结构在当时似乎是一个好主意，但多年后会产生可怕的代码和数据损坏的遗留问题？
10. 是否所有列都使用公认的Oracle内置数据类型（即没有嵌套表或用户定义类型）标量？
11. 物理数据模型图是否包含表格？
12. 该表是否可以从逻辑数据模型图中的实体派生？
13. 您是否为表及其依赖对象提供了DDL脚本？这些脚本是否在源代码管理中？
14. 表格是否符合您的建模和编码标准（如果有）？
15. 表是否在物理上正确实现（例如，所有必要的索引，如果合适，可以进行索引组织，如果合适则进行分区）？
16. 桌子是否可以防守？您会向另一位经验丰富的数据建模人员，数据库开发人员或业务用户解释它有多舒适？

正如您所知，这是一个固定列表（这就是为什么有些人投票结束你的问题）。有些观点相当不精确。它可能离您希望的模型还有很长的路要走。

人们会想要与其中一些措施争论。例如，关于非原子数据结构的观点，如JSON。当然有时这种结构是合适的;我曾经研究过一个系统，如果我们将数据存储在XMLtype列中而不是将其分解为关系表，那么这个系统就会简单得多。但那些是孤立的案件。阅读本网站上有关智能密钥，标记CSV字符串或针对实体 - 属性 - 值反模型编写查询的一些问题，以了解这些事情导致的悲痛程度。 First Normal Form应该是给定的，蔑视它的开发者不应该拥有数据库。

其他要点是领头羊。如果您的组织没有维护最新的物理数据模型，那么很可能大多数（如果不是所有的）表都不好（不可避免，很可能）。令人惊讶的是，有多少地方似乎没有将他们的DDL脚本保持在源代码管理之下。他们如何管理他们的部署以进行测试和生产？我认为祷告很重要。