To embed or reference? (Parte I)

Standard

Hola de nuevo.

Este es mi segundo post, y es algo especial ya que el 2 es uno de mis números favoritos (Es el único primo par). Al contrario de mi publicación anterior en esta no se trataran aspectos prácticos, sino que será puramente informativa.
He elegido hablar sobre un tema que me resulta particularmente interesante: “Los patrones de diseño en Mongodb”. Es claro que para abarcar todo lo relacionado con esta área un post no es suficiente, por lo que solo trataremos aspectos básicos (introductorios). Espero en un futuro (cuando haya adquirido más experiencia en el tema) poder continuar escribiendo sobre esto.
Cuando desarrollamos una aplicación, una de las primeras tareas que tenemos que llevar a cabo, es el diseño del modelo de datos. Al trabajar con bases de datos relacionales, el proceso de diseño del modelo de datos se formaliza con la “normalización”.


Como la mayoría de ustedes ya sabe, Mongodb NO es un manejador de base de datos relacionales, por lo que intentar usar la normalización no sería para nada útil. En este caso contamos con 2 opciones principales para el diseño de los modelos de datos: documentos embebidos y documentos referenciados.
El problema radica en saber cuándo aplicar cada uno de ellos. Entonces es donde surge la pregunta que lleva por título este post.
“To Embed or reference?(Embeber o referenciar)”

Antes de responder nuestra cuestión, vamos a ilustrar un poco la situación. No sé si recuerden sus clases introductorias de bases de datos (si es no, nimodo :c), una de las primeros temas que se enseñan es la normalización, que como se los decía en los párrafos anteriores, no es otra cosa más que un proceso para diseñar (o adaptar) un modelo de datos adecuado para bases de datos relacionales.

Supongamos que tenemos la siguiente tabla:

table1Imaginemos que para nuestra aplicación es muy importante guardar números telefónicos de las personas, entonces, se puede dar el caso de que alguien tenga más de un número de teléfono con el que se le pueda localizar. Nuestro modelo de datos debe permitir más de un número de teléfono por persona. Como el modelo relacional no admite guardar más de un valor por registro, debemos adaptarlo un poco más, veamos la tabla siguiente.

table2Como pueden ver la tabla anterior soluciona nuestro problema de múltiples números telefónicos, pero crea otro más grande. Al momento de consultar un número específico estamos obligados a usar una clausula ‘like’ en el query, lo cual hace la consulta más lenta. (En este caso solo tenemos un máximo de 3 números telefónicos, así que el tiempo que tarde la consulta sería despreciable, pero se puede dar el caso que se tengan 24074589536958 números de teléfono asociados, entonces eso si repercutiría).

¿Qué hacemos entonces?

table3En el caso anterior hemos agregado una columna más para cada número de teléfono que este asociado a un user_name, lo cual tampoco es óptimo pues afecta las operaciones de ‘delete’ y ‘update’.

table4Esta última tabla se ve mejor que las anteriores, pero también presenta un inconveniente. Como podrán notar, hay redundancia de datos, lo cual en determinado momento puede traducirse como inconsistencia en nuestra base de datos y nadie quiere una base de datos inconsistente.

table5table6

Lo que hemos hecho en este paso es crear dos tablas, una que contiene, el id, user_name y e-mail y la otra con los phone_number y un id que la relacionara con la primera. Al llegar a este punto se dice que nuestro modelo de datos ya está normalizado de acuerdo a las reglas de normalización para modelos de datos relacionales.

Como se dieron cuenta hacer este proceso para bases de datos relacionales no tiene mucha complejidad, pues existen reglas bien definidas para llevarlo a cabo.

En este momento han de estar pensado que diablos les importa la normalización si el tema son las bases de datos NO relaciones (Mongodb en especifico). Bueno, algo parecido es lo que se aplica a los modelos de datos en mongo.

Al principio tenía pensado abarcar todo el tema en un solo post, pero debido a que me  he extendido un poco, considero necesario dividirlo en 2 partes (para no aburrirlos). Por lo que dejaré esto hasta aquí.

Esperen la segunda parte en mi próximo post, aproximadamente en dos semanas (también pueden no esperarla).

Hasta la próxima.

 

Leave a Reply

Your email address will not be published. Required fields are marked *