如何评价数据库系统中一张表的好坏？我们需要从哪些方面来分析呢？我可以建立一个模型来进行此类评估吗？如果是的话怎么办？
最佳答案
非详尽列表。对于所有这些问题，是是一个好的答案，否是不好的答案。
- 该表格是否具有明确的业务功能？它与应用程序的目的的契合程度如何？
- 该表的名称是否正确？表的列名称是否正确？业务用户能理解他们的意思吗？
- 表有主键吗？
- 表是否对所有业务(候选)键都有唯一约束？
- 所有外键都已定义吗？
- 所有具有约束值的列是否都有指向引用数据表的外键或检查约束(或 MySQL 的
enum)？ - 所有列都具有正确(最强)的数据类型吗？
- 表格是否正确标准化？ (在 OLTP 环境中，这意味着至少 Boyce-Codd Normal Form ，而数据仓库中的情况则有所不同。)
- 该表是否不含任何包含“智能 key ”的列、CSV 字符串、JSON、XML、其含义取决于另一列(或另一表)中保存的元数据的不同数据项，或任何其他看似奇怪的结构这在当时是个好主意，但会在多年后导致可怕的代码和数据损坏？
- 所有列都是标量，使用公认的 Oracle 内置数据类型(即没有嵌套表或用户定义类型)吗？
- 物理数据模型图是否包含表格？
- 该表是否可以从逻辑数据模型图中的实体派生？
- 您有表及其依赖对象的 DDL 脚本吗？这些脚本在源代码管理中吗？
- 该表是否符合您拥有的任何建模和编码标准(如果有)？
- 表的物理实现是否正确(例如，所有必要的索引、索引组织(如果适用)、分区(如果适用))？
- 这张 table 能守住吗？您是否愿意向另一位经验丰富的数据建模者、数据库开发人员或业务用户解释它？
正如您所知，这是一个固执己见的列表(这就是为什么有些人投票结束您的问题)。有些观点相当不精确。这可能与您希望的模型相去甚远。
人们可能会对其中一些措施提出异议。例如，关于 JSON 等非原子数据结构的观点。当然，有时这种结构是合适的。我曾经开发过一个系统，如果我们将数据存储在 XMLtype 列中而不是将其分解到关系表中，那么该系统会简单得多。但这些都是孤立的案例。阅读本网站上的一些有关智能 key 、标记 CSV 字符串或针对实体-属性-值反模型编写查询的问题，以了解这些事情会造成多大的痛苦。 First Normal Form应该是一个给定的条件，而藐视它的开发人员不值得拥有数据库。
其他点是领头羊。如果您的组织没有维护最新的物理数据模型，那么很可能您的所有表(如果不是全部的话)都是坏的(不是不可避免的，只是有可能)。令人惊讶的是，有多少地方似乎没有将其 DDL 脚本置于源代码控制之下。他们如何管理测试和生产的部署？我认为祈祷很重要。
关于mysql - 如何评价数据库系统中一张表的好坏？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50264281/