一份不详尽的清单。对于所有这些问题，是的答案是好的，不是的答案是坏的。
这张table有明确的商务功能吗？它在多大程度上符合应用程序的目的？
这张table的名字好吗？表中的列是否命名良好？商业用户能理解他们的意思吗？
表是否有主键？
表对所有业务（候选）键都有唯一的约束吗？
是否定义了所有外键？
是否所有具有受约束值的列都具有引用数据表的外键或检查约束（或 enum 对于mysql）？
是否所有列都具有正确（最强）的数据类型？
table是否正常(在oltp环境中（至少意味着boyce codd范式），数据仓库中的情况是不同的。）
表中是否没有任何列包含“智能键”、csv字符串、json、xml、不同的数据项，这些数据项的含义取决于另一列（或另一个表）中的元数据，或者任何其他异国情调的结构，这些结构在当时似乎是个好主意，但在以后的几年中会导致可怕的代码和数据损坏？
所有列是否都是标量的，使用的是公认的oracle内置数据类型（即没有嵌套表或用户定义的类型）？
物理数据模型图是否包含表？
表是否可以从逻辑数据模型图中的实体派生？
您有表及其依赖对象的ddl脚本吗？这些脚本在源代码管理中吗？
表格是否符合您的建模和编码标准（如果有的话）？
表的物理实现是否正确（例如，所有必要的索引、索引组织（如果合适）、分区（如果合适）？
这张table有防御能力吗？向另一位有经验的数据建模师、数据库开发人员或业务用户解释它，您会感到多舒服？
正如你所知，这是一个固执己见的清单（这就是为什么有些人投票结束你的问题）。有些观点相当不精确。可能离你想要的模型还很远。
人们会对其中一些措施提出异议。例如，关于像json这样的非原子数据结构的观点。当然，有时这种结构是适当的；我曾经在一个系统上工作过，如果我们将数据存储在xmltype列中，而不是将其分解到关系表中，那么这个系统会简单得多。但这些都是孤立的案例。阅读本网站上有关智能钥匙、标记csv字符串或针对实体属性值反模型编写查询的一些问题，了解这些事情会造成多大的痛苦。第一个范式应该是给定的，而蔑视它的开发人员不应该拥有数据库。
其他点是领头羊。如果您的组织没有维护一个最新的物理数据模型，那么如果不是所有的表都是坏的（不是不可避免的，只是很可能）。令人惊讶的是，有多少地方似乎没有将ddl脚本置于源代码管理之下。他们如何管理测试和生产的部署？我认为祈祷很重要。