Y AHORA SÍ, HABLAMOS DE MongoDB… Las bases de datos diseñadas por MongoDB tienen, desde sus cimientos, un formato diferente a las de las bases de datos relacionales (o bases de datos basadas en tablas y SQL). Utiliza un sistema de almacenaje de información diferente, llamado BSON (binary JSON), que a su vez procede del JSON (JavaScript Object Notation). Realmente no tengo experiencia con BSON, aunque sí un poco con JSON, pero para hacernos una idea, puede servir. La forma de almacenar datos en JSON y BSON es muy parecida a la forma en la que realizaríamos, por ejemplo, al hacer un esquema-resumen de unos apuntes de clase. La información es organizada de una forma jerárquica: se crean puntos o elementos de una lista, y cada uno de esos puntos puede a su vez subdividirse libremente en el número de puntos que sea necesario. Además, ya no tenemos la rigidez de formato de las tablas de las bases de datos tradicionales y, según sea necesario, cada nivel del esquema puede almacenar tipos de datos muy diferentes. Volviendo al ejemplo de antes de la librería, la información de los clientes tendría una estructura como la que sigue: Cliente: Fulano Fulanez (Dirección, datos contacto, etc…) Compra: El conde de Mostecristo (ISBN, editorial, precio, etc) Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc) Compra: La legión maldita Cliente: John Doe (Dirección, datos contacto, etc…) Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc) Compra: Python avanzado (ISBN, editorial, precio, etc) Cliente: Pedro Falso (Dirección, datos contacto, etc…) Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc) Este formato de almacenaje de datos es más flexible a la hora de incorporar nueva información, incluso de datos que en principio no estuvieran previstos. Imaginemos que hemos creado una web de nuestra librería y queremos añadir las valoraciones que hacen los clientes: bastaría añadirlos a la misma lista, con lo que seguimos teniendo un rápido acceso a la información. Si hubiéramos usado bases de datos relacionales / SQL, habríamos tenido que crear nuevas tablas, nuevas relaciones, y aumentar la complejidad del sistema para cuando planeáramos realizar búsquedas de esta nueva información. Lo anterior quedaría como (cambios en negrita): Cliente: Fulano Fulanez (Dirección, datos contacto, etc…) Compra: El conde de Mostecristo (ISBN, editorial, precio, etc) Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc) Compra: La legión maldita Valoración: Acerca de: “El conde de Montecristo”, Comentario: “Clásico de imprescindible lectura”. Valoración: Acerca de: “Mis años con Carmele”, Comentario: “No lo recomiendo”. Cliente: John Doe (Dirección, datos contacto, etc…) Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc) Compra: Python avanzado (ISBN, editorial, precio, etc) Cliente: Pedro Falso (Dirección, datos contacto, etc…) Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc) Una alternativa sería, si así lo decidiera el diseñador de la web, limitar los comentarios a aquellos libros que el cliente haya comprado en la web, y hacer que aparecieran referidos a la compra correspondiente: Cliente: Fulano Fulanez (Dirección, datos contacto, etc…) Compra: El conde de Mostecristo (ISBN, editorial, precio, etc) Valoración: Comentario: “Clásico de imprescindible lectura”. Compra: Asesinato en el Orient Express (ISBN, editorial, precio, etc) Compra: La legión maldita Cliente: John Doe (Dirección, datos contacto, etc…) Compra: Aprender Access para principiantes (ISBN, editorial, precio, etc) Compra: Python avanzado (ISBN, editorial, precio, etc) Cliente: Pedro Falso (Dirección, datos contacto, etc…) Compra: Derecho Procesal, 1º Ed (ISBN, editorial, precio, etc) A la hora de acceder a la información, esto supone que va a ser más fácil para el motor de la base de datos: la información que necesitamos está ordenada de una forma sencilla.