La estructuración de datos en la aplicación Stormie se basa en un conjunto de tablas, en las que se definen una serie de relaciones, que permiten parametrizar los datos para ser tratados de forma automática.
Productos
¿Cómo guardar la información relativa a los productos si de una tienda a otra, los campos relacionados pueden variar de forma abismal? fue de las primeras preguntas a responder cuando comencé a dar vueltas a la estructura de datos que soportaría la aplicación.
Una de las cosas claras es que se haría uso de una tabla de productos, donde se guardarían los datos (nombre, descripción, precio) asociados a ellos. Los nombres de los campos, no podrían llamarse de una forma lógica (es decir, diferente para cada cliente en función de lo que fuese a contener), pues la aplicación debe controlar los campos de forma automática, sin necesidad de estar cambiando los nombres de los campos en los scripts. Los campos, pues, se llamarían de forma progresiva como campo_01, campo_02… menos el campo identificador, que se llamaría siempre id.
Mapeo de campos. Por este sistema, quedaba estandarizada la nomenclatura de campos, pero existían varios problemas. El primero, que en muchas ocasiones se necesita saber de qué tipo es el campo en cuestión; en base a ello Stormie toma unas decisiones u otras en la presentación o mantenimiento de datos. En segundo lugar, un campo puede ser clave ajena; la aplicación necesita saberlo para coger los datos automáticamente de la tabla relacionada. Y el tercero, es que se pierde la referencia de qué campo se está tocando; campo_07 no dirá mucho de lo que contiene si no entramos en la tabla y lo deducimos por sus valores.
Para solventar todos estos problemas, creé una tabla de mapeo, que contendría el nombre físico (campo_01, campo_02), el nombre lógico al que correspondería (título, descripción), el tipo de dato (entero, fecha…) y la tabla de quién es clave ajena (en caso de que lo fuera).
A la hora de instalar la aplicación, bastaría rellenar la tabla de mapeo y la aplicación se encargaría de todo lo demás.
Categorías
Las categorías, como los productos, podían tener estructuras muy dispares, y Stormie debía ser capaz de adaptarse a toda posibilidad. Un producto, no siempre tendría asociada una única categoría (la relación podría ser de 1 a n, de 1 a 1 o de 1 a 0), por lo que quedaba descartado meterlo como posible campo de la tabla de productos. Se crearía por tanto una tabla que relacionase los productos con las categoría/s a las que perteneciese.
En cuanto a la jerarquía… pueden existir indefinidos niveles de categorías (subcategorías, subsubcategorías..), haciendo inviable que cada nivel estuviese en una tabla. Pensando un poco, se me ocurrió indicar la jerarquía en una única tabla, usando un campo llamado nivel_previo, que contendría el id de la categoría anterior a la que perteneciese la categoría. (Si la categoría fuese de primer nivel, el valor del campo sería 0). Este campo, sería clave ajena de la propia tabla. (Modelo Jerárquico)
Añadiendo funcionalidad
Las búsquedas, los filtros, noticias, enlaces… se definen en tablas… y se comentará en el siguiente capítulo…

