[Php-avanzado] Normalización
Leonardo Tadei - Pegasus Tech Supply
leonardot en pegasusnet.com.ar
Vie Jul 6 00:32:01 ART 2012
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
Más información sobre la lista de distribución Php-avanzado