Consejos para diseñar una base de datos

ByLuis

Diseñar una base de datos no es algo sencillo y sí muy importante, ya que un mal diseño conlleva dificultades para desarrollar la aplicación o una aplicación compleja. Unos consejos que realmente son muy necesarios y muchas veces no se llevan a cabo.

  • Mal diseño: el diseño es lo fundamental, primero hay que saber qué es lo que se necesita mostrar para luego diseñar correctamente la base de datos. Yo personalmente me he encontrado con diseños iniciales muy básicos que luego han ido parcheando y haciendo modificaciones drásticas para ajustarlas a un modelo que era el mismo desde el inicio de la aplicación.
  • Ignorar la normalización: la normalización es fundamental para un buen rendimiento y una sencilla programación.
  • Nomenclatura no estándar: los nombres deben significar algo para que sea sencillo de comprender a simple vista. A parte, la nomenclatura debe ser constante en todo el diseño.
  • Falta de documentación: esto es una constante en todo el mundo de la programación, y en las bases de datos no va a ser menos. Que tu sepas que significa una tabla o un campo, no quiere decir que otra persona que entre en el proyecto vaya a saberlo con la misma facilidad que tú.
  • Una tabla que agrupa a muchas: un error normal es pensar que un diseño con muchas tablas es más complejo, y que es mejor meterlo todo en una única tabla.
  • Usar un identificador como única clave primaria: no siempre es correcto usar únicamente un identificador numérico secuencial como clave primaria única.
  • No usar las características de SQL para proteger la integridad de los datos: hay que tener en cuenta las reglas de campos nulos, tamaños de los campos y claves secundarias en el diseño para obtener una mejor integridad de datos.
  • No usar procedimientos almacenados para obtener los datos: es una forma de separar la capa de la base de datos de la capa del usuario. Aportan seguridad, encapsulamiento, mantenibilidad y rapidez. Yo también añadiría el uso de vistas.
  • Falta de pruebas: algo para mí muy importante es hacer pruebas de estres, para saber si la base de datos va a aguantar el volumen de datos que necesitará la aplicación. Comprobar el tiempo de ejecución de las sentencias para añadir índices, etc…

Podéis ver todos estos puntos muy bien explicados y de forma extensa en el artículo original.

Ten Common Database Design Mistakes

Similar Posts

|

NoSQL databases: 10 Things you Should Know About Them

ByLuis

NoSQL databases: 10 Things you Should Know About Them: 5 pros and 5 cons by Guy Harrison: Five advantages of NoSQL Elastic scaling Big data Goodbye DBAs (see you later?) Economics Flexible data models Five challenges of NoSQL Maturity Support Analytics and business intelligence Administration Expertise A few amendments though: Elastic scaling: part …

Post original

Parche para indexar Drizzle con Sphinx

ByLuis

La verdad es que se trata de algo poco usado, son dos opciones a tener en cuenta en el futuro: Sphinx y Drizzle, aunque Sphinx cada vez se usa más en proyectos con gran volumen de datos, y Drizzle también es algo que debemos tener en mente con todo lo que pueda pasar con MySQL y Oracle o simplemente porque está enfocado a web.
Pues para quien trate con ambas tecnologías le puede venir muy bien este parche para poder usar ambas a la vez.
Drizzle patch for Sphinx 0.9.9-rc2

Oracle 11g para mañana miércoles

ByLuis

OracleDespués de 9 meses de beta, Oracle anuncia que mañana saldrá a la luz la versión 11g de su base de datos.
Entre las novedades encontramos compresión de datos, tecnología flashback para la recuperación de datos y actualizaciones automáticas.
Para los ansiosos, se va a poder seguir la presentación que harán mañana (a mí me dice ahora que dentro de 1 día y 6 horas) en este enlace (se necesita Real Player).
Oracle Database 11g ready for launch

Cuando no hay que normalizar la base de datos

ByLuis

La normalización es el proceso por el cual se optimizan las tablas de una base de datos para que no haya datos redundantes, se optimice el espacio en disco y se evite errores en la actualización de datos. Ahora bien, aunque la normalización es el estado idóneo para la base de datos, eso no quiere decir que sea el más idóneo para nuestra aplicación.
Existen un caso perfecto cuando la normalización no es adecuada y es cuando la obtención de datos es lenta. Si normalizamos y eso implica que para obtener los datos tengamos que realizar varios joins, al haber muchos datos puede darse la situación de que las consultas sean lentas.
Algo parecido nos ha pasado en Bitacoras.com, ha sido necesario desnormalizar para mejorar la velocidad de respuesta. Imaginaros, teníamos que mostrar dentro de la Comunidad de los usuarios los posts de los usuarios a los que sigues y su actividad (tal sigue a cual).
Como se puede apreciar son datos totalmente distintos y lógicamente van en tablas diferentes, y a parte hay que obtener los datos de los usuarios a los que se sigue y usarlos para obtener sus posts (de todas sus bitácoras) y sus actividades y ordenarlos por fecha descendiente. Solo de leerlo ya me aparecen unos cuantos joins por la mente.
La solución ha sido crear una tabla de enlaces a ids de otras tablas. En la misma tabla tengo enlaces a los posts y a las actividades y a los ids de los usuarios. Es más rápido (unas 300 veces) debido a que existe paginación y es preferible obtener ids de dos tablas en una consulta sencilla y luego obtener n registros sencillos, que obtenerlo en una única consulta.
Otra cosa que he observado es que puede ser más rápido obtener una lista de IDs (sacadas de una consulta) y luego comparar haciendo un IN que hacer un join de dos tablas, cuando una de estas tablas se obtiene mediante una consulta.
Al final lo que nos queda es que la teoría no es siempre válida y que las situaciones en las que nos podemos encontrar hacen que la solución menos elegante sea la más efectiva