在数据库系统中如何评估一个表的好坏?

erhoui1w  于 2021-06-25  发布在  Mysql
关注(0)|答案(1)|浏览(343)

关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗?**更新这个问题,这样就可以通过编辑这篇文章用事实和引文来回答。

两年前关门了。
改进这个问题
如何在数据库系统中评估表的好坏?我们需要分析哪些方面?我能为这样的评估建立一个模型吗?如果是,那么如何?

46qrfjad

46qrfjad1#

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

相关问题