- 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.
Excelente info. Gracias
Que buena informacióm se te agradece
Buen aporte, saludos!!!
Excelente, gracias!
Excelente información, desvela muchos mitos que tenía.
Muy buena información, lo único que quizás opino que está demás, es el cómo nombrar las tablas (En plural o con prefijos), no digo que sea una buena o mala sugerencia, de hecho yo comparto la misma opinión, simplemente como dice en otro punto, ser consistentes en la manera de hacerlo y si la companía ya tiene un standard, pues apegarse a eso.
Una mas no usar triggers y procedimientos almacenados eso es de antaño, con los nuevos modelos de desarrollo, la lógica de negocios no tiene que estar en tu Base de Datos.
Justamente tengo una intriga sobre este tema, estuve investigando sobre las ORM (Mapeo Relacional de Objetos) que dicen que reemplaza en un 80 a 90% el uso de triggers y procedimientos almacenados en la lógica del negocio, pero aun no veo como prodría reemplazarlo.
Es bueno recordar….
gracias por su ayuda que nos da cada día para aprender mas.
Muy bueno!
Excelente puntos para los diseñadores de BD!!! 🙂
Totalmente de acuerdo @MANAGIT_CL
excelente informacion… muchas gracias …
No voy de acuerdo con eso de los prefijos, es de buena practica, cuando la DB no es solo puras tablas poner prefijos como tb_ = table, pr_ procedure, tr_ trigger, sq_ = sequence, dr_ directorio, etc. Imagina una base de datos con miles de procedimientos la cual no ha sido creada por ti, si no que simplemente se te dio permisos sobre el objeto. Seria dificil encontrarlos para documentarse sobre su uso o modificacion. pero con un simple select User_Objects indicando el prefijo PR_ en un like, seria simple encontrarlos y modificarlos. Recuerda la mayor parte de un programador en una empresa es entender el codigo de otros para su implementacion y modificacion ya que estaras trabajando con varias personas por debajo y sobre ti.
Estoy de acuerdo contigo, el tema de los nombres en las tablas y campos no es precisamente el mas adecuado, lo dejé así para respetar el contenido original del artículo en ingles. Creo que lo mas importante es que al menos tengas una forma de nombrarlos, ya que hay desarrolladores que ni eso tienen. Saludos Julio!
Hola, pienso que una BD con muchas tablas, procedimientos, indices y demás… puedes identificar los objetos con el diccionario de datos de oracle, por lo que no veo necesario una prefijos en los nombres de las tablas… saludos = )
Excelente información amigo, algunos puntos un poco ambiguos pero en general bien claras y concisas las recomendaciones, con respecto a los prefijos considero que no son necesarios, al menos no lo veo como buena practica según lo indica un compañero en los comentarios, para eso está la documentación, los diagrama y metadatos.
Gracias!
Gracias!
No hay mejor teoría que poner en práctica lo mejor del documento ya que se adecua de acuerdo a la necesidad del negocio y lo que se va a diseñar