[Php-avanzado] Normalización
David Barraud
davidbarraud en gmail.com
Mar Jul 10 11:41:08 ART 2012
Hola Leo, te paso las correcciones hechas con los detalles que me pediste.
*Normalización*
*#departamentos*
id_depto
depto_nombre
*#categorias*
id_categoria
nombre
*#insumos*
id_producto
id_categoria
imagen
nombre
*#RemitosAltaStock*
id_remito_alta
fecha
*#RemitosAltaStockDetalle*
id_alta_detalle
id_remito_alta
id_producto
nombre
cantidad
*#RemitosBajaStock*
id_remito_baja
fecha
*#RemitosBajaStockDetalle*
id_baja_detalle
id_remito_baja
id_producto
nombre
cantidad
motivo
*#solicitudes*
id_solicitud
id_depto
depto_nombre
id_estado
id_remito_baja
fecha_inicio
fecha_fin
problema
solucion
*#solicitudesDetalles*
Id_solicitud_detalle
Id_solicitud
Id_producto
nombre
cantidad
*#estados*
id_estado
estado
El 6 de julio de 2012 00:32, Leonardo Tadei - Pegasus Tech Supply <
leonardot en pegasusnet.com.ar> escribió:
> Hola David,
>
>
> El jue, 05-07-2012 a las 15:44 -0300, David Barraud escribió:
> > Bien, entonces me faltaría una tabla en #solicitudes que me guarde los
> > insumos que se usan para cada solicitud
>
> Me parece que decís bien, pero por las dudas lo vuelvo a expresar
> acá:
> las Solicitudes normalizadas quedan en dos tablas, una con la "cabecera"
> de la solicitud, y otra con el "detalle" en dónde constan los insumos.
>
> Si te fijás, los comprobantes de altas y de bajas son casi iguales,
> salvo que la "cabecera" es más chica (y los de baja tienen el motivo
> como parte de los detalles).
>
> > y el cálculo del stock de los insumos sería la sumatoria de las Alta
> > de Stock - baja de stock - baja de stock en las solicitudes.
>
> Correcto!
>
> > Si estoy en lo correcto decime si estas tablas quedarían de esta
> > manera:
>
> Mmm... más o menos así. La idea está bien, pero te falta pulir un
> par
> de detalles:
>
> 1) Los nombre de las tablas en plural, y lo de los campos en singular.
> Parece una pavada pero es de veras importante para no confundirte.
> 2) Si tenés id_depto, como tu RF1 dice que se gestionan, tenés que
> guardar acá el nombre del departamento, porque si después se cambia o se
> borra, no tenés que cambiar las Solicitudes ya generadas.
> Nota: No pasa lo mismo con id_estado, porque no se gestiona.
> 3) La tabla de detalles se ve bien. A nivel de nomenclatura, es un poco
> confuso porque el "remito" es la solicitud entera, así que uno esperaría
> que la palabra "remito", si está, esté en la primer tabla. Si una tabla
> se llama "Solicitudes", la otra podría llamarse algo como
> "SolicitudesDetalles" o "SolicitudesItems", es decir un nombre que
> denote que depende de la primera y que no tiene sentido sin ella.
> Yo empiezo todo con "Solicitudes...", pero esto es de viejo mañoso,
> porque después el ver las tablas alfabéticamente se ven juntas las
> relacionadas, y no con otras tablas en el medio, pero sería un nombre
> más correcto "ItemsSolicitud" o "DetallesSolicitud"... más correcto pero
> incómodo.
> Mientras sea claro y explícito, llamalas como quieras. Que una diga
> "Remito" y la otra no, desentona, pero no es que en nombres de tablas o
> de campos haya cosas "mal" si son representativas.
>
> Saludos!
>
>
> > #solicitudes
> >
> > id_solicitudes
> >
> > id_depto
> >
> > id_estado
> >
> > fecha_inicio
> >
> > fecha_fin
> >
> > problema
> >
> > solución
> >
> >
> >
> > #RemitoBajaStockSolicitudes
> >
> > id_baja_solicitudes
> >
> > id_solicitudes
> >
> > id_producto
> >
> > nombre
> >
> > cantidad
> >
> >
> > Muchas gracias!
> >
> >
> >
> > El 5 de julio de 2012 01:09, Leonardo Tadei - Pegasus Tech Supply
> > <leonardot en pegasusnet.com.ar> escribió:
> > Hola David,
> >
> > El mié, 04-07-2012 a las 17:53 -0300, David Barraud escribió:
> > > Hola Leo, ya voy entendiendo mejor lo de los remitos, vamos
> > a la parte
> > > de dar de baja el stock del insumo.
> >
> >
> > Veamos!
> >
> > > Voy a tener 2 mecanismos para dar de baja el stock:
> > > 1. cuando se rompe o se tira algún insumo.
> > > 2. Cuando se usa algún insumo en la solución de la solicitud
> > de
> > > trabajo.
> >
> >
> > Ok.
> >
> > > En el primer caso las tablas serían similares al remito de
> > Alta de
> > > Stock, salvo que se agregaría un campo con el motivo de su
> > baja.
> >
> >
> > Estoy de acuerdo.
> > En este caso, agregá al diccionario del remito de baja
> > el "motivo".
> >
> > > En el segundo caso la solicitud generaría un nuevo remito de
> > baja del
> > > stock. Estoy en lo correcto?
> >
> >
> > Es más simple!
> > La Solicitud de Reparación _es_ un comprobante de
> > baja, y en su
> > cabecera tiene todos los datos de la Solicitud...
> >
> > De la misma forma por ejemplo, en un sistema
> > comercial, el remito de
> > compra tendrá en su cabecera todos los datos del proveedor, el
> > nro de
> > remito, la fecha en que fue emitido, etc.
> >
> > Vos estás pensado en que la Solicitud genere un nuevo
> > comprobante de
> > baja, pero esto es más complicado, porque tendrías que
> > discriminar los
> > comprobantes según por dónde vienen para por ejemplo hacer un
> > informe de
> > los insumos usados (y no de los tirados).
> > Pero lo más importante no es que es más complicado,
> > sino que sería un
> > artificio que no refleja la realidad. La realidad sería
> > imaginarte como
> > sería esto si tuvieras que hacer comprobantes en papel para
> > reflejar
> > cada movimiento de stock... llegarías sin dudas a tener tres:
> > el remito
> > de alta (posiblemente incluyendo el proveedor por las
> > garantías), el
> > remito de baja por roturas en dónde en cada item habría lugar
> > para poner
> > el motivo, y la solicitud de reparación, que tendría una
> > cabecera más
> > grande y algunos renglones en blanco para poner los insumos
> > que se usan,
> > si es que se usan.
> >
> > Cómo lo ves a la luz de esto que te cuento?
> >
> >
> >
> > > Si todo esto es correcto te paso la nueva normalización a
> > ver qué
> > > opinás.
> > >
> > >
> > > Normalización
> > >
> > > #departamentos
> > >
> > > id_depto
> > >
> > > nombre
> > >
> > >
> > >
> > > #categorias
> > >
> > > id_categoria
> > >
> > > nombre
> > >
> > >
> > >
> > > #insumos
> > >
> > > id_producto
> > >
> > > id_categoria
> > >
> > > imagen
> > >
> > > nombre
> > >
> > >
> > >
> > > #RemitoAltaStock
> > >
> > > id_remito_alta
> > >
> > > fecha
> > >
> > >
> > >
> > > #RemitoAltaStockDetalle
> > >
> > > id_alta_detalle
> > >
> > > id_remito_alta
> > >
> > > id_producto
> > >
> > > nombre
> > >
> > > cantidad
> > >
> > >
> > >
> > > #RemitoBajaStock
> > >
> > > id_remito_baja
> > >
> > > fecha
> > >
> > >
> > >
> > > #RemitoBajaStockDetalle
> > >
> > > id_baja_detalle
> > >
> > > id_remito_baja
> > >
> > > id_producto
> > >
> > > nombre
> > >
> > > cantidad
> > >
> > > motivo
> > >
> > >
> > >
> > > #solicitudes
> > >
> > > id_solicitudes
> > >
> > > id_depto
> > >
> > > id_estado
> > >
> > > id_remito_baja
> > >
> > > fecha_inicio
> > >
> > > fecha_fin
> > >
> > > problema
> > >
> > > solución
> > >
> > >
> > >
> > > #estados
> > >
> > > id_estado
> > >
> > > estado
> > >
> > >
> > >
> > > En la tabla solicitudes el campo id_remito_baja sería un
> > campo nulo ya
> > > que en el caso de que la solicitud de trabajo no necesite
> > insumos para
> > > solucionar el problema, no es necesario generar un remito de
> > baja de
> > > insumo por lo que este campo no tiene ningún dato.
> >
> > > _______________________________________________
> > > Php-avanzado mailing list
> > > Php-avanzado en pato2.fi.mdp.edu.ar
> > >
> > http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> >
> > --
> > Leonardo Tadei
> > leonardot en pegasusnet.com.ar
> > Blog: http://blog.pegasusnet.com.ar
> > Firma pública:
> > http://www.pegasusnet.com.ar/LeonardoTadei-public.key
> >
> > _______________________________________________
> > Php-avanzado mailing list
> > Php-avanzado en pato2.fi.mdp.edu.ar
> > http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
> >
> >
> > _______________________________________________
> > Php-avanzado mailing list
> > Php-avanzado en pato2.fi.mdp.edu.ar
> > http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
> --
> Leonardo Tadei
> leonardot en pegasusnet.com.ar
> Blog: http://blog.pegasusnet.com.ar
> Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key
>
> _______________________________________________
> Php-avanzado mailing list
> Php-avanzado en pato2.fi.mdp.edu.ar
> http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://www3.fi.mdp.edu.ar/pipermail/php-avanzado/attachments/20120710/827fd605/attachment-0001.html>
Más información sobre la lista de distribución Php-avanzado