a Freelance Web Developer

Siempre he sido un defensor del rollito de tener tu propio dominio y de que tus cuentas de correo pertenezcan a él. Tenía la sensación de que esto trasmitía seriedad y profesionalidad.

Ahora he cambiado de opinión, creo que lo que trasmite profesionalidad es conocer y saber utilizar las mejores herramientas a las que se tiene acceso.

Ya no quiero tener mi correo en mi dominio, quiero tener mi correo en Gmail, quiero que él se encargue de todo, despreocuparme, saber que va a funcionar.

Hace mucho leí a un viejo colega como definía su plan de todo en la red, y me llamó mucho la atención. Hace ya tiempo que llevo con mi propio plan de todo en la red, pero el paso del email ha sido el más costoso y difícil de tomar para mí.

Ahora que lo he hecho no me arrepiento:

* Adiós a la configuración del servidor de correo, no conozco servicio más difícil de configurar.

* Adiós al Spam: el arma de doble filo: no recibo Spam, no se me toma por Spam.

* El Autoresponder: parece una tontería, pero configurar esto si el servidor de correo te lo has montado tú con un Postfx no es tan trivial.
* Si quiero tengo pop y smtp e imap y seguridad y todos esos rollos, también de una dificultad ridícula de configurar.

* Todas las chorradas de un cliente de correo: filtros, etiquetas, buscador, estrellitas, …

* Si envío un mensaje siempre está ahí como enviado no como antes que si lo envío desde casa sólo estaba en el ordenata de casa, lo mismo si marco un mensaje como leído o importante o cualquier cosa, la misma configuración la compartiré acceda desde el ordenador que acceda.

* Gestor de múltiples cuentas y notificación en el firefox.

* Increíble alubíon de emails cuando abro el thunderbird en un ordenata donde hace mucho que no lo abro.

* Optimización de lectura del correo desde la PDA.

* Ya no me preocupo de si el servidor se cae, o se borran cosas, que se ocupen la gente de Gmail.

* Conservar el mismo correo siempre, pertenezca a la empresa que pertenezca en cada momento.

* … y además gratis :)

Este va a ser un post muy técnico así que, querido/a amigo/a, si pasabas por aquí en busca de lectura ligera mejor continuas surcando tu blog-roll.

Lo que voy a intentar explicar aquí es una cuestión de diseño de un modelo relacional de base datos aparentemente muy sencillo pero que me está generando enormes dudas existenciales y repetidos re-factors de nuestra implementación.

Supongamos que tenemos en nuestro diseño de clases un bean (pojo o como queramos llamarlo), al que llamaremos Element que contiene un número indeterminado de elementos de otra clase bean que llamaremos SubElement.

Hasta aquí todo bien, para traducir esto a un modelo de base de datos nos basta con un relación 1 a n entre una tabla ELEMENT y otra SUB_ELEMENT.

El problema viene cuando existe otra clase de beans que también, entre sus atributos, se encuentra uno que contiene un número indeterminado de beans de clase SubElement, como se muestra en la figura 1.

Es aquí cuando la relación 1 a n se complica pues ya no puedo definir una clave entre la tabla SUB_ELEMENT y la tabla ELEMENT_TYPE_1 pues puede que el registro de la tabla SUB_ELEMENT deba estar relacionado en realidad con registro de la tabla ELEMENT_TYPE_2.

La primera aproximación que se me ocurre es definir dos tablas diferentes para los objectos de clase SubElement. Una tabla (SUB_ELEMENT_TYPE_1) contendrá aquellos registros que se tengan que relacionar con la tabla ELEMENT_TYPE_1 y otra (SUB_ELEMENT_TYPE_2) contendrá los que se tengan que relacionar con la tabla ELEMENT_TYPE_2. Como se muestra en la figura 2.

Esta implementación me empezó a disgustar desde el primer momento por el hecho de tener 2 tablas diferentes que en realidad contenían registros del mismo tipo de objeto, sin contar con que si aparece otro tipo de objeto que a su vez contenga también objetos del tipo SubElement habría que sumar otra tabla más con toda la lógica de persistencia que conlleva. Así que seguí buscando.

En un pequeño brainstorming entre mis compañeros se nos ocurrió que podíamos diseñar una tabla para acoger los objetos de tipo SubElement que tuviera una referencias externa a una de las tablas ELEMENT_TYPE_X pero sin definir a cual. Para saber a qué tabla había pertenecía había que hacer uso de un nuevo campo en la tabla SUB_ELEMENT cuyo valor, sacado de un catálogo limitado, nos indicase a qué tabla real pertenecía el ID que hacía las veces de clave externa. Como se muestra en la figura 3.

Esta propuesta cumple nuestro deseo de agrupar todos los elementos de tipo SubElement en la misma tabla reutilizando también toda la implementación de la capa de persistencia. Nos ahorramos también el tener que crear nuevas tablas para alojar objetos tipo SubElement cada vez que surja una nueva clase tipo ElementTypeX. Pero surge un enorme problema de integredad referencial y es que tenemos que desprendernos de crear una clave externa en la tabla SUB_ELEMENT pues esa clave aveces pertenecerá a la tabla ELEMENT_TYPE_1 y otras a la tabla ELEMENT_TYPE_2, como ya hemos dicho esto depende de campo ELEMENT_TYPE. Esto puede causar que existan registros en la tabla SUB_ELEMENT que estén apuntando a registros en la tablas ELEMENT_TYPE_X que no existan.

Estaba apunto de elegir esta propuesta como definitiva, pues aunque tiene peligro de integridad me resultaba la más fácil de administrar y era un modelo mucho más escalable, cuando apareció este dibujo en mi cuaderno, ver figura 4.

A primera vista parece bastante más complicado que los anteriores, y lo es, pero no mucho. Aparecen unas nuevas tablas que hacen de puente entre la tabla SUB_ELEMENT y las tablas ELEMENT_TYPE_X. Estas tablas hay que duplicarlas cada vez que aparezca un nuevo objeto tipo ElementTypeX pero no acogen más que una relación y los objetos reales, los SubElement, se encuentran todos agrupados en la misma tabla.

Esta implementación dificulta las sentencias SQL de inserción, búsqueda y eliminación. Es la única pega que todavía me carcome.

Ruego, paciente lector que has llegado hasta aquí, que si tienes alguna sugerencia o corrección que hacer para llegar a una solución más ágil que ésta, sin que se perjudique la seguridad en la integración, seas tan amable y orgulloso de resumírmela.