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

Dispone de un cliente que permite acceder a los datos mediante los protocolos TCP, TCPS, HTTP o HTTPS. A diferencia de otras OODB, en este caso los objetos solo existen en el servidor, en la aplicación solo se tratan de objetos distribuidos.

Otra de las características a destacar es que tiene un sistema de anti-corrupción de datos, si unos bloques del sistema de ficheros están corruptos, no se pierde la BD.

MyOODB

Las características que ofrece esta base de datos nos encontramos con:

• Ligera: poco uso de memoria y posibilidad de configurar el tamaño del cache.
• Operaciones sencillas: cada base de datos tiene un único fichero de disco.
• Robustez: totalmente transaccional, la recuperación es total y automática.
• Ramificaciones: se pueden hacer a cualquier nivel.
• Extensible
• Rutas: cada objeto tiene una ruta mediante con la cual se puede acceder.
• Enlaces simbólicos

CowDb

Se trata de una extensión para PHP5 que permite leer y escribir data dentro de los scripts PHP, incluyendo procedimientos para acceder a los datos de SQL Server 2005 y SQL Server 2000 (incluyendo Express Edition), y hace uso de las características de PHP, como la lectura y escritura de objetos grandes.

Existe también un blog y un foro.

SQL Server 2005 Driver for PHP

Vía / International PHP Magazine

El outer join se usa cuando queremos que obtener todos los campos de una tabla que cumplen una condición y los campos de otra tabla que coinciden con los de la primera tabla.

Imaginamos que tenemos una tabla de palabras en inglés y una tabla de traduciones:

Tabla : palabras
id / palabra
 1 / bird
 2 / flower
 3 / sky
 4 / tree

Tabla: traducciones
id / traduccion / idioma
 1 / pájaro     / es
 3 / cielo      / es

Se trata de tener la tabla de palabras y sus correspondientes traducciones (en este caso solo lo he hecho para español, pero se podrían incluir registros para otros idiomas). Si nos fijamos veremos que un join normal no lo podremos hacer porque si igualamos el id de palabras y traducciones habrá registros que no se mostrarán en la tabla de palabras porque no existen sus correspondientes en la tabla de traducciones. Por ello deberemos ejecutar las siguientes instrucciones en MySQL y Oracle:

/* MySQL */
SELECT *
  FROM palabras
  LEFT OUTER JOIN traducciones
    ON palabras.id = traducciones.id

/* Oracle */
SELECT palabra, traduccion
  FROM palabras, traducciones
 WHERE palabras.id = traducciones.id (+)

Echadle un vistazo al resto de representaciones gráficas de los joins porque son muy aclaratorias.

A Visual Explanation of SQL Joins

Uno de las prioridades de Oracle es hacerse un hueco en la web2.0, para lo cual en colaboración de Zend pretende sacar este driver para así poder realizar aplicaciones que necesiten la robustez de la base de datos Oracle.

Oracle Contributes Open Source Driver for PHP

Junction mapea la base de datos a objetos, permitiendo al desarrollador concentrarse en otros detalles de la aplicación. Debido a ello no nos tendremos que preocupar más en las sentencias CRUD.

Además de lo dicho anteriormente, Junction por ahora permite cláusulas WHERE sencillas, configuración de la base de datos, capa DAO, tests y buena documentación ya sea en el código como para el usuario final.

Juntion PHP

Vía / PHPDeveloper.org

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

Funciona con cualquier base de datos compatible con ADODB, como MySQL, Microsoft Access o PostgreSQL. La información que contiene una BD: el esquema de la BD, las tablas, campos y propiedades, es suficiente para poder realizar unas clases que permita crear, editar, actualizar y eliminar registros, una base para que el desarrollador luego pueda realizar su aplicación web más facilmente.

El framework phpCG permite construir aplicaciones PHP orientadas a objetos que sean extensibles, portables y escalables.

phpCodeGenerator

Vía / International PHP Magazine

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

No se trata de una base de datos relacional, sino documental. Es distribuida, robusta, con replicación incremental con detección de conflictos. Permite realizar querys e índices.

Aunque no es una base de datos orientada a objetos (en el sentido de capa para un lenguaje de programación), si que los documentos son objetos que están formados por nombres de campos y valores (texto, números y fechas).

CouchDb puede ser útil para aplicaciones como foros, bug tracking, wikis, to-dos y mucho más. Aún está en fase alpha, esperemos que llegue a la calidad y popularidad de otras bases de datos como MySQL.

CouchDb

El libro está formado por 17 capítulos:

• Introducción: introducciones sobre Oracle y PHP.
• Extensiones PHP para Oracle: extensiones Oracle, OCI8 y PDO.
• Instalación de Oracle Database 10g Express Edition: aunque el manual se centra en esta versión, también es válida para cualquier versión de Oracle actual.
• Uso de Oracle Database 10g: trabajar con SQLs, PLs, crear usuarios, monitorear las sesiones, crear conexiones a la BD, crear informes y mucho más.
• Instalar Apache: tanto en Linux como en Windows.
• Instalar PHP: OCI en PHP4 y PHP5 tanto para Linux como para Windows y PDO en Linux y Windows.
• Instalar Zend Core para Oracle: instalación y administración de Zend Core para Oracle.
• Conectar a Oracle mediante OCI8: tipos de conexión, variables de entorno de Oracle, cerrar conexiones Oracle (algo que se suele olvidar hacer la gente).
• Ejecutar SQL mediante OCI8: inserciones, modificaciones, transacciones, errores OCI8, tunning de aplicaciones.
• Usar PL/SQL en OCI8: crear procedimientos, errores, cursores.
• Objetos grandes: LOBs y BFILEs.
• Uso de XML en Oracle y PHP: uso de la extensión SimpleXML y acceso a datos de Oracle mediante HTTP.
• Globalización: manipulación de Strings, Locale, codificación de caracteres de los HTML, formato de fechas y números.
• Debug.
• Testing: ejecutar tests OCI8, fallo en los tests, creación de tests.
• Nombre de funciones OCI8 en PHP.
• Extesión de Oracle obsoleta: comparación entre la extensión Oracle y OCI8.

The Underground PHP and Oracle Manual

Vía / Christopher Jones on OPAL

Entre las características que ofrece nos encontramos con la posibilidad de administrar varios servidores, soporte a múltiples versiones de PostgreSQL, administración de usuarios, grupos, bases de datos, esquemas, etc..., manipulación sencilla de datos, exportar los datos a diferentes formatos, importar sentencias SQL y mucho más.

Ahora solo falta que hagan algo para Oracle para hacerme feliz.

phpPgAdmin

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

• 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