我怀疑我的大部分列表都很难放入规则引擎中,但这里是:
如果可能的话,我会让它报告任何定义为比可以存储在记录(不包括 varchar(max) 和文本类型字段)和/或数据页中的字节宽的表。
如果可能的话,我希望所有相关的 PK 和 FK 列具有相同的名称。唯一不可能的情况是,当您需要在同一个表中包含与一个 PK 相关的两个 FK 时,即使这样,我也会将其命名为 PK 的名称以及描述差异的前缀或后缀。例如,如果我有一个 PersonID PK 并且一个表需要同时包含销售代表 ID 和客户 ID,它们将是 CustomerPersonID 和 RepPersonID。
我会检查以确保所有 FK 都有索引。
我想知道所有必需但没有默认值的字段。根据具体情况,您可能不想定义默认值,但我希望能够轻松查看哪些不希望找到应该具有默认值的那些。
我希望检查所有触发器以查看它们是基于集合的,而不是设计为一次运行一行。
没有定义唯一索引或 PK 的表。没有 PK 超过一个字段的表。没有 PK 不是 int 的表。
没有对我正在使用的数据库使用保留字的对象名称。
名称中没有包含“日期”一词且未定义为日期或日期时间的字段。
没有关联审计表的表。
没有未加密的名为 SSN、SocialSecurityNumber 等的字段。任何名为 CreditCardNumber 的字段都相同。
没有用户定义的数据类型(至少在 SQL Server 中,这些数据类型比它们的价值要麻烦得多。)
没有调用其他视图的视图。经验告诉我,这些通常是等待发生的性能灾难。尤其是当它们的层数超过一层时。
如果使用复制,则没有没有 GUID 字段的表。
所有表都应该有一个 DateInserted 字段和 InsertedBy 字段(即使有审计,如果这些信息很容易获得,通常更容易研究数据问题。)
在命名中一致地使用相同的大小写。没关系,只要都用同一个就好。
没有包含名为 ID 的字段的表。满怀热情地讨厌这些。他们太没用了。如果是 PK,则 ID 字段应命名为 tablenameID,如果是 FK,则应命名为 PK 名称。
对象名称中没有空格或特殊字符。换句话说,如果您需要对数据库进行特殊处理以在查询的正确上下文中识别它,请不要使用它。
如果它还要分析代码,我想查看任何使用游标或相关子查询的代码。为什么从一开始就制造性能问题?
我想看看一个 proc 是否使用动态 SQl,如果是,它是否有一个名为 Debug 的输入位变量(如果 Debug 变量设置为 1,则代码只打印动态 SQl 语句而不执行它) .
我希望能够检查是否有多个语句导致数据库中的操作(插入/更新/删除)在 proc 中还有一个显式事务和错误捕获来滚动整个事情如果它的任何部分失败,则返回。
我相信我能想到更多。