[Php-avanzado] Normalizar MUCHOS productos

[Leonardo Tadei - Pegasus Tech Supply]

Hola Gerardo,

El lun, 12-07-2010 a las 18:50 -0300, Gerardo Valiani escribió:
>         
>         > 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.  

	Bueno, por eso se habla de "elicitar" requerimientos... palabra que no
existe en castellano, sino que es una castellanización de to elicit.


>         >  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!

	Tal y como decís, esta es la forma correcta de guardar un árbol en una
tabla.
	Sin embargo, si sabés de antemano que solo habrá Rubros y SubRubros,
creá una tabla para cada uno y relacionalas.
	No te compliques!

>                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. 

	Pero Gerardo! 
	Marca y Packaging seguro serán atributos fijos y no variables o
desdconocidos como planteás: podés generar sendas tablas para esto,
ponerles un ID en la tabla de Artículos y tenés todo.

	En mi experiencia, es una mala idea cotizar y empezar un trabajo sin
conocer todos los informes que emitirá (salvo que te paguen por mes de
trabajo, en cuyo caso nada de esto importa).
 	Incluso si fuera un desarrollo para vos mismo, decidite qué informes
valen la pena y partí desdes ahí.

>                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.

	La combinación de datos a cruzar para elaborar informes de datos con
repetición es:

m! / (m - n)!

donde M son la cantidad de elementos y N de a cuentos se toman. El peor
escenario es m = n que, para solo 10 campos da: 3628800 informes ....

	Saludos!

-- 

Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key