Buenas prácticas para el uso de Bases de Datos

  1. Usa nombres consistentes y bien definidos para tablas y columnas (ejemplo: Escuela, CursoEstudiante, etc)
  2. 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.
  3. No incluyas espacios en los nombres de la tablas.



  4. No uses prefijos innecesarios  (como TblEscuela, o EscuelaTabla, etc.)
  5. Mantén los passwords encriptados por seguridad. Desencriptalos en la aplicación si es necesario.
  6. 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).
  7. Elige columnas con tipos enteros (o sus variantes) par indexar.  Una columna con tipo varchar puede causar problemas de rendimiento.
  8. 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.
  9. Provee siempre de autenticación para el acceso a base de datos. No le des el rol de  administrador a cada usuario.
  10. No uses querys del tipo “select * ” a menos de que sea necesario, extrae solo las columnas necesarias para un mejor rendimiento.
  11. 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.
  12. Particiona tu base de datos separando las tablas que se usan mucho de las que no se usan tanto para un mejor desempeño.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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.

17 thoughts on “Buenas prácticas para el uso de Bases de Datos

  1. 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.

    1. 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.

  2. 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.

    1. 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!

    2. 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 = )

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *