[Php-avanzado] datos tesis

[Federico Rafaelli]

Hola Leo, volviendo al tema estamos de acuerdo con el funcionamiento de la tabla, es como lo habia planteado en el esquema original con la tabla "comp_op", pero ahora cambiamos el enfoque, ya que las op ya no existen como entidad aparte, a si que la tabla sera como me indicaste, algo asi:
 
comp_rel
----------
id_compPpal(PK)
id_compRel(PK)
importe_aplicado
 
Me parece que tendrian que ir los dos campos como clave principal para evitar duplicaciones.
Por otro lado, perdon por mi ignorancia pero no entendi el termino "hardcodeado".
Tambien se entiende perfecto el esquema de una tabla por comprobante y esta mas que justificado, es la profundidad de detalle con el que va a trabajar el sistema la que debemos evaluar.
Saludos!
> From: leonardot en pegasusnet.com.ar> To: php-avanzado en pato2.fi.mdp.edu.ar> Date: Tue, 30 Dec 2008 15:13:03 -0200> Subject: Re: [Php-avanzado] datos tesis> > Hola Federico,> > El mar, 30-12-2008 a las 16:52 +0000, Federico Rafaelli escribió:> > Leo, la tabla de la relacion n-a-n, la que nos dara la informacion del> > detalle de la OP no se como armarla tomando las OP como comprobante ya> > que como decis vos, me quedarian ids de la misma tabla, aunque unas> > representen OP y otras fc o nc.> > Es exactamente igual:> > ComprobantesRelacion> --------------------> id_principal> id_relacionados> > En dónde id_principal es el comprobante en "que te parás" para ver los> relacionados, y id_relacionados son los comprobantes que se relacionan> con el principal.> > Agregarás un registro por cada comprobante que se refiera a otro> comprobante. Por ejemplo si el comprobante con id 34 se relaciona con> los comprobantes con id 3,5 y 11, la tabla tendrá:> > id_principal id_relacionados> 37 3> 37 5> 37 11> > Las tuplas jamás se repiten, así que pueden definirse como "unique".> Esta tabla no necesita un campo "id" ya que no se accede a los> registros de a uno, pero ponerlo como clave primaria no molesta para> nada.> > > Por otro lado me parece lo mejor tomar una tabla general para los> > comprobantes y discriminar por el tipo, ya que si llevo una tabla por> > tipo de comprobante el dia de mañana si llego a trabajar con otro tipo> > tendria que agregar una tabla nueva! en cambio con una tabla para los> > tipos solo es agregar una entrada en la misma.> > A nivel de datos, tenés razón.> Sin embargo en tu programa tendrás hardcodeado "si es 1, es factura y> suma", "si es 3 es NC y resta", etc.> > En los sistemas de mucho volumen de transacciones, se usa una tabla por> comprobante, así no hay tablas con millones de registros, lo que hace> que el sistema se ralentice. Esto permite además que si algún> comprobante lo requiera, tenga datos extra sin aumentar la tabla para> todos (por ejemplo "fecha de vencimiento", que no tiene sentido para un> recibo ni para una nota de crédito.).> A nivel del código esto es igual, porque ahora lo hardcodeado es el> nombre de la tabla y no el id.> > Como te decía desde un principio, ambos enfoques son válidos.> Tu enfoque es posible porque solo manejás cabeceras de los> comprobantes: si manejaras también lo detalles (items) como por ejemplo> la tesis de Edwin, tendrías 2 tablas por cada tipo de comprobante y una> más por cada relación necesaria!> > > Me trabe un poco con el tema, me parece que me enrosque, espero que> > los festejos de año nuevo me despejen... jaja!!> > Venís bien. Lo importante es no parar!> Saludos!> -- > Leonardo Tadei> leonardot en pegasusnet.com.ar> 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
_________________________________________________________________
Disfrutá los mejores contenidos en MSN Video.
http://video.msn.com/?mkt=es-xl
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://www3.fi.mdp.edu.ar/cgi-bin/mailman/private/php-avanzado/attachments/20090102/f51f29b3/attachment.htm