- Usa nombres consistentes y bien definidos para tablas y columnas (ejemplo: Escuela, CursoEstudiante, etc)
- Usa nombres en singular para las tablas (Estudiante en lugar de Estudiantes). La tabla representa una colección de entidades, pero no es necesario usar nombres en plural.
- No incluyas espacios en los nombres de la tablas.
- No uses prefijos innecesarios (como TblEscuela, o EscuelaTabla, etc.)
- Mantén los passwords encriptados por seguridad. Desencriptalos en la aplicación si es necesario.
- Usa enteros como identificadores para todas la tablas. Si un identificador no es requerido en el momento, probablemente los sea en el futuro (para asociar tablas o indexar).
- Elige columnas con tipos enteros (o sus variantes) par indexar. Una columna con tipo varchar puede causar problemas de rendimiento.
- Usa campos de tipo bit para almacenar valores booleanos. Usar enteros o varchar repercute en un consumo innecesario de almacenamiento. Incluso los nombres de esas columnas puedes ponerles el prefijo «Is» o «Es» en español.
- Provee siempre de autenticación para el acceso a base de datos. No le des el rol de administrador a cada usuario.
- No uses querys del tipo «select * » a menos de que sea necesario, extrae solo las columnas necesarias para un mejor rendimiento.
- Usa un framework o marco de trabajo ORM (Mapeo Relacional de Objetos) como hibernate, oBatis, etc, si el código de tu aplicación es lo suficientemente grande. Los problemas de rendimiento de los ORMs pueden manejarse detallando sus parámetros de configuración.
- Particiona tu base de datos separando las tablas que se usan mucho de las que no se usan tanto para un mejor desempeño.
- Para bases de datos grandes, sensibles y sistemas de misión crítica, usa los servicios de recuperación de desastres y servicios de seguridad como el failover clustering, respaldos automáticos, replicación, etc.
- Usa constraints (llaves foraneas, Checks, valores no nulos, etc) para la integridad de detos. No hagas todo el control desde el código de la aplicación.
- La falta de documentación en una base de datos es mala idea. Documenta tu diseño de base de datos con esquemas de entidad
relacionales (ER) e instrucciones. Incluso escribe lineas de comentarios en tus trigers, procedimientos almacenados y otros scripts. - Usa indices para scripts frecuentemente usados en tablas grandes. Hay herramientas de análisis que puede ser usadas para determinar donde pueden estar definidos
los indices. Para queries que extraen un rango de registros, índices agrupados usualmente son mejores. Para queries de punto los indices no agrupados son la mejor opción. - Un servidor de base de datos y un servidor web deben estar en máquinas diferentes. Esto provee de mas seguridad y separan la carga de trabajo en dos CPUs y memoria diferentes.
- Imágenes y columnas de tipo blob no deben estar definidas en tablas frecuentemente requeridas para evitar problemas de rendimiento. Estos datos deben ser puestos en tablas separadas relacionadas por un identificador.
- La normalización debe ser usada cuando sea requerida para optimizar el performance. Una baja normalización puede repercutir en una repetición de datos, una sobre normalización puede tener efectos en el rendimiento a causa de las excesivas uniones entre tablas para extraer datos. Se debe mantener un equilibro.
- Usa tanto tiempo como puedas para diseñar tu base de datos, el tiempo que gastes para el diseño de la base de datos es tiempo que no emplearas rediseñando la base de datos mas tarde.