<br><br><div class="gmail_quote">El 12 de julio de 2010 14:40, Leonardo Tadei - Pegasus Tech Supply <span dir="ltr">&lt;<a href="mailto:leonardot@pegasusnet.com.ar" target="_blank">leonardot@pegasusnet.com.ar</a>&gt;</span> escribió:<br>

<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
Hola Gerardo,<br>
<br>
El lun, 12-07-2010 a las 10:30 -0300, Gerardo Valiani escribió:<br>
<div>&gt;         Hola Gerardo!<br>
&gt;<br>
&gt;                seguro que hay una solución normalizada para esto.<br>
&gt;                Con el asunto de que la normalización sigue a un modelo<br>
&gt;         matemático, todo conjunto de datos es normalizable.<br>
&gt;<br>
&gt;                Para normalizarlo, tenés que partir de la lista de<br>
&gt;         todas las<br>
&gt;         cosas a guardar: tenés esa lista armada???<br>
&gt;<br>
&gt;<br>
&gt; No. No tengo esa lista. Con lo cual, me doy cuenta que quiero hacer<br>
&gt; algo que es imposible. El problema es que ni el cliente conoce todos<br>
&gt; sus productos.<br>
<br>
</div>        Esto no es necesariamente un problema, porque lo que tenés que<br>
encontrar son estructuras, no datos.<br>
        Por ejemplo, sabés como normalizar direcciones con ciudades, provincias<br>
y países sin saber ni todos los países que serán cargados, y sabiendo<br>
incluso que es raro que alguien sepa todas las provincias de todos los<br>
países, y ni hablar de las ciudades...<br>
<br>
        Me explico?<br></blockquote><div><br>Si, perfectamente. El tema es que el cliente no conoce la estructura.  <br></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">



<div><div></div><div><br>
<br>
&gt;                Las tablas resultantes dependen únicamente de los datos<br>
&gt;         a<br>
&gt;         guardar...<br>
&gt;<br>
&gt;                Generalmente esas soluciones para el caso que planteás,<br>
&gt;         en el<br>
&gt;         peor escenario, quedan de la forma:<br>
&gt;<br>
&gt;         Artículos:<br>
&gt;         id<br>
&gt;         cod<br>
&gt;         des<br>
&gt;<br>
&gt;         Atributos:<br>
&gt;         id<br>
&gt;         atributo<br>
&gt;<br>
&gt;         AtributosArticulos:<br>
&gt;         id<br>
&gt;         id_articulo<br>
&gt;         id_atributo<br>
&gt;         medida<br>
&gt;<br>
&gt;                ... es decir, una relación muchos a muchos entre los<br>
&gt;         Artículos y<br>
&gt;         sus Atributos.<br>
&gt;                Fijate que ahora para el atributo &quot;largo&quot; usado en el<br>
&gt;         tornillo,<br>
&gt;         pondrás los mm de la longitud, y para el atributo &quot;apertura&quot;<br>
&gt;         usada en la<br>
&gt;         pinza pondrás cuanto abre.<br>
&gt;<br>
&gt;<br>
&gt; Que sencillo! No me habia dado cuenta.<br>
<br>
</div></div>        No es nada genial de mi parte: es solo la normalización.<br>
        (los geniales acá fueron Boyd y Codd ! )<br>
<div><br></div>
<div><br>
&gt;  Para esto se me ocurrio agregar otra tabla &quot;valores&quot; con los campos:<br>
&gt; id, valor. Y cambiar en la tabla AtributosArticulos el campo medida,<br>
&gt; por id_valor.<br>
&gt; * Con esta normalizacion el campo medida o valor, sera siempre del<br>
&gt;mismo tipo, varchar. Creo que seria el mas adecuado. No podre variar<br>
&gt;con integer, float, etc. En si, en la gran mayoria de los atributos, no<br>
&gt;voy a hacer calculos. Por lo que el tipo varchar creo que estaria bien.<br>
&gt;Que opinan al respecto?<br>
&gt;<br>
</div>        Muy complicado...<br>
        Lo que podrías hacer, asumiendo que los Artículos estén además<br>
organizados por Rubros (o SubRubros) es que el sistema defina atributos<br>
para cada rubro, de manera tal de que cuando cargue un destornillador,<br>
solo le aparezcan los atributos que le corresponden.<br>
        Esto es más largo de poner en marcha, pero más preciso. Además si el<br>
usuario cargó que un atributo de los destornilladores es &quot;de cruz&quot;, lo<br>
edita, y automáticamente todos pasan a decir &quot;phillips&quot;.<br>
<div><br></div></blockquote><div>Si, voy a hacer esto. Va a ser lo mejor. </div><div>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!</div>
<div> </div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<div><br></div>
        Bien, llegados a este punto, pregunto: tenés que emitir listados<br>
organizados por los criterios de los atributos? qué rol funcional<br>
cumplen en el sistema?<br></blockquote><div><br>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. <br>
 </div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">


        Porque si es solo para tener la descripción, poné un campo text para<br>
que escriban lo que quieran, y creale un índice fulltext para buscar con<br>
LIKE ahí adentro lo que sea que hayan escrito... si no lo encuentran, es<br>
porque no lo escribieron así, y no hay reclamo.<br></blockquote><div><br></div><div>Fue lo primero que pense. Pero por el tema de los informes me heche atras.</div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">

<br>
        Reordá la &quot;metodología de programación&quot; KISS !!!<br></blockquote><div>Ni idea de eso. Lo voy a googlear.</div><div><br></div><div>Saludos!</div></div>