[Php-avanzado] Normalizar MUCHOS productos

Gerardo Valiani gerardovaliani en gmail.com
Lun Jul 12 18:50:04 ART 2010


El 12 de julio de 2010 14:40, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:

> Hola Gerardo,
>
> El lun, 12-07-2010 a las 10:30 -0300, Gerardo Valiani escribió:
> >         Hola Gerardo!
> >
> >                seguro que hay una solución normalizada para esto.
> >                Con el asunto de que la normalización sigue a un modelo
> >         matemático, todo conjunto de datos es normalizable.
> >
> >                Para normalizarlo, tenés que partir de la lista de
> >         todas las
> >         cosas a guardar: tenés esa lista armada???
> >
> >
> > No. No tengo esa lista. Con lo cual, me doy cuenta que quiero hacer
> > algo que es imposible. El problema es que ni el cliente conoce todos
> > sus productos.
>
>         Esto no es necesariamente un problema, porque lo que tenés que
> encontrar son estructuras, no datos.
>        Por ejemplo, sabés como normalizar direcciones con ciudades,
> provincias
> y países sin saber ni todos los países que serán cargados, y sabiendo
> incluso que es raro que alguien sepa todas las provincias de todos los
> países, y ni hablar de las ciudades...
>
>        Me explico?
>

Si, perfectamente. El tema es que el cliente no conoce la estructura.

>
>
> >                Las tablas resultantes dependen únicamente de los datos
> >         a
> >         guardar...
> >
> >                Generalmente esas soluciones para el caso que planteás,
> >         en el
> >         peor escenario, quedan de la forma:
> >
> >         Artículos:
> >         id
> >         cod
> >         des
> >
> >         Atributos:
> >         id
> >         atributo
> >
> >         AtributosArticulos:
> >         id
> >         id_articulo
> >         id_atributo
> >         medida
> >
> >                ... es decir, una relación muchos a muchos entre los
> >         Artículos y
> >         sus Atributos.
> >                Fijate que ahora para el atributo "largo" usado en el
> >         tornillo,
> >         pondrás los mm de la longitud, y para el atributo "apertura"
> >         usada en la
> >         pinza pondrás cuanto abre.
> >
> >
> > Que sencillo! No me habia dado cuenta.
>
>         No es nada genial de mi parte: es solo la normalización.
>        (los geniales acá fueron Boyd y Codd ! )
>
>
> >  Para esto se me ocurrio agregar otra tabla "valores" con los campos:
> > id, valor. Y cambiar en la tabla AtributosArticulos el campo medida,
> > por id_valor.
> > * Con esta normalizacion el campo medida o valor, sera siempre del
> >mismo tipo, varchar. Creo que seria el mas adecuado. No podre variar
> >con integer, float, etc. En si, en la gran mayoria de los atributos, no
> >voy a hacer calculos. Por lo que el tipo varchar creo que estaria bien.
> >Que opinan al respecto?
> >
>         Muy complicado...
>        Lo que podrías hacer, asumiendo que los Artículos estén además
> organizados por Rubros (o SubRubros) es que el sistema defina atributos
> para cada rubro, de manera tal de que cuando cargue un destornillador,
> solo le aparezcan los atributos que le corresponden.
>        Esto es más largo de poner en marcha, pero más preciso. Además si el
> usuario cargó que un atributo de los destornilladores es "de cruz", lo
> edita, y automáticamente todos pasan a decir "phillips".
>
> Si, voy a hacer esto. Va a ser lo mejor.
Ahora, como hago un tabla de rubro y subrubros. Pienso en campos como: id,
id_padre, rubro. Donde id_padre seria un id de la misma tabla de algun rubro
ya cargado. Ahora si esto esta bien, como hago una query que me devuelva
todo el arbol de rubros y subrubros? Me mato!


>
>        Bien, llegados a este punto, pregunto: tenés que emitir listados
> organizados por los criterios de los atributos? qué rol funcional
> cumplen en el sistema?
>

A primeras, no tienen rol funcional. Pero en el futuro habran informes. Ej:
mostrar la cantidad de articulos vendidos en el ultimo mes agrupados por
marca, y packaging. Por dar un ejemplo.


>        Porque si es solo para tener la descripción, poné un campo text para
> que escriban lo que quieran, y creale un índice fulltext para buscar con
> LIKE ahí adentro lo que sea que hayan escrito... si no lo encuentran, es
> porque no lo escribieron así, y no hay reclamo.
>

Fue lo primero que pense. Pero por el tema de los informes me heche atras.

>
>        Reordá la "metodología de programación" KISS !!!
>
Ni idea de eso. Lo voy a googlear.

Saludos!
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20100712/61356360/attachment.htm 


Más información sobre la lista de distribución Php-avanzado