CMS, campos de una tabla configurables

Hola,
Estoy pensando en desarrollar el CMS para una tienda desde cero, había pensado en tener una tabla productos, en los que tuviesen la información básica (Nombre, Descripción y Precio). Luego había pensado que a través de plugins se pudiese extender esa "tienda base" a otros tipos de tienda, por ejemplo añadir campos para las fotos, o si es de ropa, le metes el plugin de tallas y te permitiría poner a cada producto una serie de tallas. Podría pasar lo mismo con colores por ejemplo u otro tipo de opciones.

Había pensado en tener una tablar productos base (tbl_products), luego otra tabla para los nuevos campos (tbl_attributes_extra con campos para id_campo y valor_campo) y finalmente una que relacionase el atributo extra con el producto (tbl_meta_prod_attr) (Habría otra que indicase que si el producto es tal tipo, hay que buscar los atributos tales y cuales en tbl_meta_prod_attr con campos id_producto id_attributo). Mi problema es al intentar pensar en una tienda con un par de centenares de productos, que se convierten facilmente en miles de campos y la consulta podría ser algo pesada. Además, no sé de qué tipo guardar la información, porque un atributo puede ser un texto largo (una review de un usuario por ejemplo) o un número (la altura del producto por ejemplo).

Eso es lo que quiero optimizar para usar los menos recursos posibles. En principio había pensado en crear la tabla tbl_attributes con un campo para cada tipo y que se guardase en el campo que ma se adecuara al atributo en sí (eso lo diría el plugin), pero entonces tendría una tabla enorme, con la mayoría de campos vacios.... ¿Alguna idea a mi problema?

PS: No, no voy a usar un CMS prefabricado, la idea es crearlo desde cero.

Estoy haciendo lo mismo. Armar tablas y campos nuevos para cada cosa es una locura. Yo tengo los productos clasificados en familias y un campo Extra en cada tabla: familia y producto. En ambos guardo valores separados por coma, en el de familia los nombres, en el de productos los valores. Dado que es muy común un listado de valores fijos entre los que elegir, uso un separador distinto | para posibles valores múltiples. Luego solo parseo la data en el cliente y armo dinámicamente los formularios. Para búsquedas no es ideal no mucho menos, pero en tanto no tengas miles de productos zafa. Eso si, los campos extras son por familias (todos los productos de esa familia tienen los mismos campos extra) sino ya es un descontrol

Jorge

WOW! Conejo olvido su contraseña... pero ¿pero como? wtf

Hola jorge, lo que has tratado de hacer es un especie de Documents Based system sin usar queries con Foreign Keys.

El producto de tu ecommerce conceptualmente es un objeto, que contiene todo tipos de atributos, atributos en idioma, atributos de stock etc entonces porque no guardarlo como documents en tu base de datos y de hecho te ahorras el diseño de la arquitectura de tus datos.

deberias mirar MongoDb o el ya conocido Couchdb

sé que facebook y muchos sitios de las redes sociales estan desarrollado de esta forma.

saludos

Muy interesantes las DB basadas en objeto, las estoy mirando y seguramente las pruebe si puedo instalarlas en el servidor. Dado que Conejo perdió su password, hemos discutido por Tweeter acerca de la posibilidad de hacer búsquedas con el sistema que propongo ... lo cierto es que es bastante dificultoso dado que hay que buscar en un campo de texto por posiciones relevantes (es decir hay un parseo de por medio, incluso REGEXP) y si hay muchos registros la cosa va realmente lenta. Mi target son pequeñas tiendas de 100 productos, para mucho volúmen, quizás una DB basada en documentos como la que propone papachan sea la opción

Jorge