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

Question

我们如何评估一个表在数据库系统中的好坏？我们需要分析哪些方面？我能为这样的评估建立一个模型吗？如果是，那怎么做？

Answer 1

并非详尽无遗的清单。对于所有这些问题，是的是一个好的答案，而不是是坏的。

1. 这张桌子有明确的业务功能吗？它是否符合应用程序的目的？
2. 这张桌子叫得好吗？表的列名好吗？业务用户会明白他们的意思吗？
3. 这个表有主键吗？
4. 表是否对所有业务(候选)键都有唯一的约束？
5. 所有外键都定义好了吗？
6. 是否所有具有约束值的列都具有引用数据表的外键或check约束(或enum for MySQL)？
7. 是否所有列都具有正确(最强)的数据类型？
8. 桌子正规化了吗？(在OLTP环境中，至少意味着Boyce-Codd范式，数据仓库中的情况不同。)
9. 表是否没有任何列，这些列包含“智能键”、CSV字符串、JSON、XML、含义依赖于另一列(或另一表)中的元数据的不同数据项，或者任何其他异域结构，这在当时似乎是个好主意，但在多年后会导致可怕的代码和数据损坏？
10. 是否所有列都使用公认的Oracle内置数据类型(即没有嵌套表或用户定义的类型)进行标量？
11. 物理数据模型图是否包括表？
12. 表是否可以从逻辑数据模型图中的实体派生？
13. 您有表及其依赖对象的DDL脚本吗？这些脚本在源代码管理中吗？
14. 该表是否符合您的任何建模和编码标准(如果有的话)？
15. 表的物理实现是否正确(例如，所有必要的索引、索引组织(如果适当)、分区(如果适当))？
16. 这张桌子站得住脚吗？您对另一个有经验的数据建模师、数据库开发人员或业务用户解释它会有多舒服呢？

如你所知，这是一个固执己见的清单(这就是为什么有些人投票结束你的问题)。有些观点相当不精确。这可能离你所期望的模特还有很远的路。

人们会想要反对其中的一些措施。例如，关于像JSON这样的非原子数据结构的要点。当然，有时这种结构是合适的；我曾经使用过一个系统，如果我们将数据存储在XMLtype列中而不是将其分解到关系表中，这个系统就会简单得多。但这些都是孤立的案例。在这个网站上阅读一些关于智能键、标记CSV字符串或针对实体属性值反模型的查询的问题，以了解这些事情造成了多大的痛苦。第一范式应该是给定的，而那些无视它的开发人员不应该拥有数据库。

其他要点是领头羊。如果您的组织没有维护最新的物理数据模型，那么如果不是所有的表都是坏的(不是不可避免的，只是可能的)，那么它很可能是最坏的。令人惊讶的是，许多地方似乎没有将DDL脚本置于源代码控制之下。他们如何管理他们的部署来测试和生产？我觉得祷告很有特色。