Sospecho que la mayor parte de mi lista sería difícil de poner en un motor de reglas, pero aquí va:
Si es posible que tendría que informar de las tablas que se definen como más ancho que los bytes que puede almacenarse en un registro (excluyendo varchar (max) y campos de tipo de texto) y/o una página de datos.
Quiero que todas las columnas PK y FK relacionadas tengan el mismo nombre si es posible. El único momento en que no es posible es cuando necesita tener dos FK en la misma tabla relacionados con un PK, e incluso entonces, le pondría el nombre del PK y un prefijo o sufijo que describa la diferencia. Por ejemplo, si tuviera un PK de PersonID y una tabla necesaria para tener tanto la identificación del representante de ventas como la identificación del cliente, serían CustomerPersonID y RepPersonID.
Verificaría para asegurarse de que todos los FK tengan un índice.
Me gustaría conocer todos los campos que se requieren pero que no tienen ningún valor predeterminado. Dependiendo de lo que sea, es posible que no desee definir un valor predeterminado, pero me gustaría poder ver fácilmente cuáles no esperan encontrar los que deberían tener un valor predeterminado.
Me gustaría que verificaran todos los triggers para ver que están basados en el conjunto y no están diseñados para ejecutarse en una fila por vez.
Ninguna tabla sin un índice exclusivo definido o PK. No hay tabla donde el PK es más de un campo. No hay tabla donde PK no es un int.
No hay nombres de objetos que usen palabras reservadas para la base de datos que estoy usando.
No hay campos con la palabra Fecha como parte del nombre que no están definidos como fecha o fecha y hora.
Ninguna tabla sin una tabla de auditoría asociada.
Ningún campo llamado SSN, SocialSecurityNumber, etc. que no está encriptado. Lo mismo para cualquier campo llamado CreditCardNumber.
No hay tipos de datos definidos por el usuario (en SQL Server al menos, estos son muchos más problemas de lo que valen.)
No hay puntos de vista que se llaman a otros puntos de vista. La experiencia me ha demostrado que a menudo son un desastre de rendimiento que espera suceder. Especialmente si capas más de una capa de profundidad.
Si usa la replicación, no hay una tabla sin un campo GUID.
Todas las tablas deben tener un campo DateInserted y el campo InsertedBy (incluso con la auditoría, a menudo es más fácil de los problemas de investigación de datos, si esta información está fácilmente disponible.)
El uso consistente del mismo caso en el nombramiento. No importa cuál sea el tiempo que todos usen el mismo.
No hay tablas con un campo llamado ID. Odio esto con una pasión. Son tan inútiles. Los campos ID deben llamarse tablenameID si es PK y con el nombre PK si es FK.
No hay espacios ni caracteres especiales en los nombres de los objetos. En otras palabras, si necesita un manejo especial para que la base de datos lo reconozca en el contexto correcto en la consulta, no lo use.
Si también va a analizar el código, me gustaría ver cualquier código que use un cursor o una subconsulta correlacionada. ¿Por qué crear problemas de rendimiento desde el principio?
Me gustaría ver si un proceso usa SQl dinámico y si es así si tiene una variable de bit de entrada llamada Debug (y código para imprimir solo la declaración SQl dinámica y no ejecutarla, si la variable Debug está configurada en 1)
Me gustaría poder verificar si hay más de una declaración que causa una acción en la base de datos (insertar/actualizar/eliminar) que también hay una transacción explícita en el proceso y captura de errores para rodar el todo Lo devuelve si alguna parte de ella falla.
Estoy seguro de que podría pensar en más.