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

Similar Posts

| |

Usar polimorfismo en PHP5 para acceder a diferentes BD

ByLuis

Gracias al tratamiento de objetos que nos permite PHP5, es posible diseñar aplicaciones de una forma más eficiente. Un caso de ello es el polimorfismo, lo cual va a permitir acceder y trabajar con diferentes tipos de bases de datos de una forma única.
En el artículo en el que hacemos referencia, explican detalladamente cómo usar el polimorfismo para acceder a datos mediante MySQL y SQLite. Para ello se crearán una clase abstracta y dos clases que extenderán de esta, siendo cada una de estas las encargadas de tratar el acceso a MySQL o a SQLite.
Después se deberá crear una clase que maneje estas clases, dependiendo de un parámetro, se usará una de las clases (MySQL o SQLite). Esta última clase será la que instancie el usuario final, por lo que para él será transparente el tratamiento que se haga de una u otra base de datos.
Algo que también destacaría de este artículo es la forma de no hacerlo, algo que me he encontrado en alguna ocasión en Java (donde hay polimorfismo desde siempre). La forma incorrecta de hacerlo es creando una única clase y diferenciando en cada método diferentes códigos dependiendo de si se trata de una BD u otra.
Abstracting Database Access Using Polymorphism with Objects in PHP 5

Instalar Cassandra en Ubuntu

ByLuis

Con tanta noticia de Cassandra y Twitter, me ha dado por instalar Cassandra en local. No soy un experto en Ubuntu, más bien soy un poco torpe en algunas cosas de administración, pero bueno, si yo lo he conseguido ¿por qué no ayudar a aquellos que pueden ser tan torpes como yo?

Lo primero que hay que hacer es bajarse la última versión: http://cassandra.apache.org/#download

Una vez descomprimido y renombrada la carpeta a cassandra, lo muevo al directorio /opt:

sudo mv cassandra /opt/

Luego creamos unos cuantos directorios necesarios para la aplicación:

sudo mkdir -p /var/lib/cassandra/{commitlog,data,callouts,staging}
sudo mkdir /var/log/cassandra
sudo chmod -R 777 /var/lib/cassandra/

Creamos el fichero /var/log/cassandra/system.log y le damos permisos de escritura:

sudo chmod 777 /var/log/cassandra/system.log

Bueno, pues esto ya está instalado, ahora solo falta ejecutar Cassandra y luego probarlo con la aplicación CLI:

/opt/cassandra/bin/cassandra -f &
/opt/cassandra/bin/cassandra-cli -host localhost -port 9160

Podéis hacer pruebas con los ejemplos que salen aquí.

Actualizado: Armonth me indica un truco que simplifica la creación de los directorios, muchas gracias.

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

Miles de modelos de datos gratuitos

ByLuis

Para quien no sea muy hábil diseñando modelos de datos, o no tenga tiempo o simplemente no tenga ganas de pensar, os mostramos una lista de modelos de datos gratuitos que podemos usar en nuestras aplicaciones. Son del todo variopintos, puedes encontrar modelos de datos para blogs, e-commerce, clientes, facturas, compañías de ballet, comunidades indígenas, registro de payasos, ONGs, workflows, … vamos, que si no lo encuentras sería algo bastante extraño.
Library of Free Data Models
Vía / dzone

|

WWW SQL Designer: diseño de bases de datos online

ByLuis

WWW SQL Designer es una aplicación online que nos permite editar nuestro propio modelo de datos y exportarlo a diferentes bases de datos como MSSQL, MySQL, Oracle o PostgreSQL. A parte permite exportar a XML, importar a XML, guardar directamente en base de datos y leer desde base de datos.
sqldesign.png
La creación de las tablas y de las relaciones entre ellas es sencillo, para las relaciones solo es necesario desplazar la PK en una tabla y el campo y la relación se crearán automáticamente.
La aplicación se puede descargar y nos permite guardar nuestros trabajos. La interfaz me ha gustado mucho ya que permite mover las tablas, las relaciones se redibujan cuando las tablas se organizan, tiene una pantalla de zoom para movernos a la posición que queramos y la edición de los campos y tablas es muy sencillo.
WWW SQL Designer
Vía / DbRunas