Consejos para el diseño de bases de datos a nivel de empresa

Question

trabajo con una aplicación empresarial y han recogido algunos consejos para el diseño de DB

1. Todas las tablas deben tener los siguientes campos que ayuda en el seguimiento de auditoría - LastChangedBy, LastChanged, LastChangedPage
2. Todos sus procedimientos almacenados que tienen SQL dinámico deben tener el parámetro @bDebug. De manera predeterminada, está establecido en 0. Si está configurado en 1, imprima la declaración de SQL dinámico y esto será realmente útil para la depuración.
3. Para los SP CRUD, tenga una forma de actualizar parcialmente la tabla. Si su tabla tiene 10 campos y en uno de los SP, se preocupa por actualizar solo 5 campos, tiene una capa de abstracción para hacer esto.

¿Alguna otra sugerencia útil que se pueda imaginar?

EDIT: Gracias por todas las respuestas. Todavía estoy buscando una respuesta que pueda proporcionar un enlace a sugerencias/trucos/estrategias para DB Design.

Answer 1

En mi opinión uno requeriría CreatedBy y Creado campos.

Answer 2

Para # 1: muévase a SQL Server 2008 y simplemente active Cambiar captura de datos. Si realmente necesita mantener registros detallados de auditoría, esta característica sola justificará el costo.

Para el n. ° 2: Cualquier procedimiento almacenado con sql dinámico debe someterse automáticamente a doble secreto (es decir, está permitido, pero tiene que pasar por varios niveles de revisión del código para asegurarse de que no hay una mejor manera de hacerlo) .

Answer 3

Cuando se trata de la potencia de la web, es mejor nunca borrar nada. Por lo tanto, tiene una fecha de eliminación que puede simplemente excluir aquellos objetos que han sido "eliminados" de sus búsquedas. Esto también ayuda a los clientes frenéticos que accidentalmente borraron su cuenta. Obviamente, esto no debe usarse en todos los campos.

Answer 4

Un par de pensamientos que inmediatamente vienen a la mente cuando se trabaja con la base de datos muy grande (VLDB):

poner en práctica en caso de que la partición de tablas?

Las tablas de bases de datos grandes, con millones de registros, pueden beneficiarse de la partición de tablas.

• La disponibilidad de esta característica de SQL Server se limita al uso de la Enterprise Edition.
• La aplicabilidad depende de el hardware de su plataforma y la disponibilidad de de una clave de particionamiento apropiada dentro de los datos de la tabla.

¿Cuáles son las tablas a las que he accedido con más frecuencia?

Considere la separación por grupo de archivos, es decir, coloque la tabla de clientes en un grupo de archivos y la tabla de transacciones en otro. Esto permite que SQL Server cree varios subprocesos para el acceso a archivos, creando la posibilidad de E/S secuenciales.

A continuación, considere la estructura del disco físico subyacente, es decir, un LUN separado para cada grupo de archivos.

Diseñar una estrategia de ajuste flexible

Usted, sin duda ya tienen una estrategia de indexación en cuenta sin embargo para las plataformas VLDB este debe revisarse con frecuencia. A medida que aumentan los volúmenes de datos y cambia la distribución de los datos, los planes de ejecución para sus consultas de acceso a los datos pueden cambiar. Debe planificar la necesidad de revisar periódicamente su estrategia de indexación.

Answer 5

LastChangedBy etc. campos son bastante inútiles. Si realmente necesita un seguimiento de auditoría, necesita tablas de auditoría separadas que detallen los cambios y mantengan un historial de auditoría. Si no necesita un seguimiento de auditoría, los campos LastChangedBy etc. solo se agregan al trabajo sin valor comercial.

Answer 6

Las fechas deben almacenarse en formato Utc y convertirse a la hora local en el cliente.