¿Que enfoque de programación utilizarias?
 

Aquí en el changarro tenemos nos hemos dado cuenta que de repente al tener 2 o 3 proyectos en marcha a la vez, asignados a diferentes programadores, salen a relucir diferentes prácticas y costumbres. Si bien hay una guía de estilo más o menos definida al final invariablemente cada quien le pone su toque.

Hace unos días nos reunimos para unificar criterios respecto a algunas funciones y tareas que a fuerza de ser repetitivas o utilizarse mucho en casi todos los proyectos requieren ponernos de acuerdo. Una de estas tareas es la siguiente:

Sea una tabla "facturas" que contiene n registros. Sea otra tabla "recibos" que contiene también n registros y a su vez una tabla "det_recibos" que contiene los números de factura incluidos en el recibo. Desde el punto de vista de diseño, un recibo es un conjunto de facturas que se llevan o traen en algún momento dado y que posteriormente regresan a su lugar. Un recibo permanece "activo" o "abierto" mientras no se le indique lo contrario. Una factura solo puede ser incluida en un recibo que esté abierto siempre y cuando dicha factura no esté ya incluída en otro recibo abierto. Es decir, solo puede aparecer en un recibo abierto a la vez.

Basado en las reglas anteriores vemos que hay dos enfoques ya hablando de la programación de las tablas.

1.- Incluir un campo "num_recibo" en la tabla "facturas" para colocar ahí el número del recibo(abierto) en el que dicha factura está incluida, al cerrar el recibo se borra el mismo de las facturas. De esta forma basta la tabla de facturas para consultar cuales se encuentran incluidas en determinado recibo

2.- No incluir el campo y hacer las consultas utilizando las 3 tablas mediante joins para determinar si una factura ya se encuentra en x recibo.


Personalmente me gusta más el enfoque 2 ya que no hay que hacer modificaciones a la tabla "facturas" pero el enfoque 1 también funciona aunque implica más operaciones al momento de crear un recibo.

¿Ustedes que opinan?, ¿Hay alguna otra alternativa?, ¿Ustedes como lo hacen?

Desde hace muchos años intento evitar a toda costa cualquier posible incongruencia entre diferentes tablas.

Podría darse el hipotético caso de que existiese un registro en la tabla de 'enlace' que no se corresponda bien a una factura o bien a un recibo. .... por la causa que sea ...

Por lo tanto, para mí queda claro que utilizaría la opción 1, grabando dentro de la propia tabla de facturas el número de recibo correspondiente.

;)

Sino agregases un campo RECIBO a la tabla FACTURAS, cómo harías para saber a cuál recibo está relacionada una factura?

opción 1, cabe anotar que si ya está en un recibo dicha factura, supongo que no se elimina del detalle, pero en el detalle si dice si la factura está activa o el recibo está activo, como sea, lo importante es si la información está correcta el join entre las tablas es suficiente para la tarea.

Poner el código de la factura en los recibos.

Chris, para saber si una factura esta en un recibo activo hago esto:

Código SQL [-]
SELECT FACTURAS.NUM_FACTURA, RECIBOS.NUM_RECIBO FROM
FACTURAS
JOIN DET_RECIBOS ON (DET_RECIBOS.NUM_FACTURA=FACTURAS.NUM_FACTURA)
JOIN RECIBOS ON (RECIBOS.NUM_RECIBO=DET_RECIBOS.NUM_RECIBO)
WHERE FACTURA.NUM_FACTURA=:NUM_FACTURA AND RECIBOS.ACTIVO=1

Obviamente pasándole el parámetro del número de factura que quiero verificar si ya está en algún recibo abierto. Esta misma consulta la puedo utilizar para saber en que otros recibos aparece la factura en cuestión con solo quitarle la condición de buscar solo en activos.

Al final los dos enfoques funcionan pero lo que me hace roncha es que en el caso de la opción 1, tengo que además de hacer las modificaciones a la tabla de recibos, tengo que hacerlo también en la de facturas. En el otro caso, la tabla de facturas nunca sufre cambios.

Hola

creo que tambien utilizaría el de agregar el campo a la tabla factura,

aunque tambien le daria vueltas a una tercera opción :D:Dy es (aunque esto se parece a la solucion nº 2....)

3.- crear otra tabla en donde se vincule recibo y factura... aunque esta sea solo para saber si la factura pertece a un recibo... y a su vez cuantas facturas estan en un determinado recibo..

Salu2:D:p

Hola.

Opcion 1.
Aunque signifique codificar más, algo es seguro: si tengo el número de recibo, tengo el recibo.
( o al menos sé cuál es el que no tengo...) :)


Un saludo.

Yo utilizaría el método 1.... y validaría con el método 2, na mas pa amarrar... pero definitivamente el punto 1 debería ser utilizado.

respecto al comentario de mi amigo BlueSteel, permíteme discrepar con tu idea, ya que el crear una tabla extra, implica al menos crear tres campos en esa tabla, además de un índice y las llaves que correspondan, cuando en el primer caso estamos hablando de agregar un solo campo; además de que el join en lugar de ser de 3 tablas, se tiene que hacer de 4 tablas... en otras palabras, un campo es más sencillo de administrar, que tres o más campos, mas todo lo que esto implique.

y ahora, pa seguir haciendo relajo... no me gusta usar guiones para nombrar las cosas, prefiero usar CamelCase; además, la tabla del detalle, yo la llamaría RecibosDetalle, en lugar de DetalleRecibos. Esto es porque si estoy buscando los recibos, todas las tablas relacionadas a estos, estarán una junto a la otra y no tendría necesidad de moverme entre las tablas. En el otro caso, tendría que ir a la R para ver los recibos y luego ir a la D y buscar el DetalleRecibos ahí.

Pero como dicen, para gustos, los colores....

Hola.

Particularmente opino que lo más simple es la opción 1 y como soy un poco perro suelo tirar por la vía más simple siempre, aparte de que será bastante más rápido que tirar de consultas.

Saludos

Acabo de hacerme un <ER> mental y llego a la conclusión de que lo lógico es poner en el recibo el identificador de la factura. La razón es que es más fácil que una factura se pague con varios recibos, mientras que lo raro es que un recibo pague varias facturas. Useasé:

Código SQL [-]
CREATE TABLE recibo (
  ...
  id_factura ...,
  FOREIGN KEY id_factura(factura.id)
)

Otra posibilidad sería utilizar una relación <n-n>, esto es, una tabla tal que así:

Código SQL [-]
CREATE TABLE rel_factura_recibo (
  id_factura ...,
  id_recibo ...,
  FOREIGN KEY id_factura(factura.id),
  FOREIGN KEY id_recibo(recibo.id)
)

Ahora mismo no recuerdo si las claves externas se indican así, pero creo que se entiende la idea, ¿no?

De todas formas prefiero la solución que he expuesto primero.

[edito]

Acabo de releer el problema y he caído en que mi lógica no es válida. La definición que pones de recibo es un poco rara, ¿no? Un recibo es el documento que se entrega cuando se "recibe" una cantidad de dinero, en este caso el importe de una factura, ¿o no?

Eso es lo que pienso yo.

Por eso mismo me he quedado callado después, me "suena" raro ese recibo del que hablan.

Bueno antes de opinar me gustaría, mi buen amigo AzidRain :D, que definieras ¿a qué le llamas Recibo? o que entiendes por recibo?, pues la verdad estoy al igual que Ñuño Martínez que estoy viendo que la definicion que le pones a un recibo es diferente a la que tengo yo; quizás sea por la diferencia de País..:D.. pero mejor acláranos....;)
Saludos...:)

Yo creo que falta algo en la explicación. La existencia de la tabla det_recibos hace pensar que entre recibos y facturas hay una relación n-n. Por otra lado, la posibilidad de incluir el campo num_recibo en la tabla factura hace pensar que en realidad se trata de una relación 1-n.

Entonces, más que preguntarse si es buena idea incluir el campo num_recibo en facturas, yo preguntaría ¿para qué se quiere la tabla det_recibo?

// Saludos

Se pone bueno el tema, el nombre "recibo" es un genérico, pudiera llamarse de cualquier forma, pero les comento como es el proceso de negocios de este cliente para este particular:

1.- Se tiene una tabla que contiene todas las facturas que hay pendientes de cobro
2.- Todos los días se le entregan facturas a cobradores para que las vayan a cobrar, se les hace una relación que indica que facturas se lleva y se guarda con su nombre para identificar quien tiene que factura.
3.- Al regresar el cobrador, se retoma la relación que se capturó y se indica que facturas si se cobraron y cuales quedaron pendientes y se "cierra" la relación, con lo que se indica que esas facturas ya regresaron a su lugar.
4.- Al día siguiente se repite la operación.

Así como este ejemplo hay muchos procesos que he visto en muchas empresas que utilizan un esquema similar, se tiene una tabla de x cosa y se requiere ir haciendo relaciones de esas x cosas.

Ahora comento lo que menciona Roman:

Tenemos una tabla facturas, tenemos una tabla "lista_facturas" y a su vez una de detalles de esta última "det_lista_facturas".

La relación entre facturas y listas es 1-n aunque realmente no es una relación verdadera pues no siempre una factura está incluida en una lista.

Ya. Pero eso en realidad no contesta lo que comento.

Más bien pensaría que especificaras que hace la tabla det_recibo y nos restrinjamos al problema inicial en lugar de añadir tablas :p

// Saludos

Me parece super engorroso, seguramente no lo he entendido.

Si tienes una tabla de facturas, sólo has de tener un campo para controlar si está cobrada. Igual sólo necesitas un campo para saber dónde están, basta el código del cobrador. Si tiene un código es que la tiene un cobrador, si tiene valor cero es que está en la oficina.
O sea, todo ese proceso y tablas se soluciona con 2 campos en la tabla de facturas.
Lo de los recibos... pues sigo sin entenderlo :)

Pues estoy en la misma de ustedes, no termino de comprenderle la mano. :o

Por otro lado, como sugerencia, creo que sería más apropiado si se mueve el hilo a un mejor lugar... porque si lo siguen tratando en la taberna, en una charla acompañada de alcohol el DER saldrá medio medio :D :p

Saludos,

Ya está movido al foro de Debates...:)

Coincido con la engorrosidad que mencionan varios compañeros pero ni hablar, así lo quiere el cliente, al fina creo que quedo convencido de meter un campo adicional en la tabla principal.

Respondiéndole a Román, la tabla det_recibo solo contiene 2 campos: el numero de recibo y el num de factura, y sirve solo para enlazar la tabla de recibos con la tabla de facturas.

Otra cosa que no he comentado es que curiosamente este sistema se hizo "al revez" pues primeramente se desarrolló el módulo de cuentas por cobrar y posteriormente el de facturación. No me cuestionen mucho, pues como siempre así lo quiso el cliente a pesar de todas las recomendaciones habidas y por haber. En un principio la facturación trabajaba sobre archivos dBASE y las cuentas por cobrar en MySQL, posteriormente se desarrolló la facturación ya sobre MySQL pero ya rascándole empiezan a aparece cosas medio incongruentes como las que les comenté.

La cantinela de siempre. Luego se quejarán cuando algo no funcione, o les digamos que costará más de lo que pretenden pagar, o que tardaremos más tiempo... Y claro, cuando la cosa esté a medias dirán eso de "Ya que estás haciendo esto, añade esto otro también, que total no te cuesta nada." Y peor aún, cuando esté terminado dirán "Pues está bien, pero ahora se me antoja que funcione exactamente al contrario. Y estoy seguro de que no tardarás más de cinco minutos en cambiarlo, porque ya está hecho casi todo." Si lo sabré yo. :mad:

Yo sigo sin entenderlo, así que no puedo aportar más, pero estaré atento a lo que propongáis a ver si aprendo. :)

Pues a mí me sorprende todo ésto:eek:... aunque no tengo demasiada experiencia en creaciones de software como la que tiene nuestro amigo AzidRain:D, pero siempre que una empresa me ha pedido un desarrollo de software a medida, por nada, ellos han intervenido en el diseño de la base de datos;)...digo no?...se supone que ellos no tienen conocimiento de diseño de BD, ellos te dicen lo que desean tener en el software y te dan toda la información de como trabajan y como desean que el software trabaje, pero a que se metan en el diseño de la BD? pues... digo ¿no?.:confused:
Lo que a ellos les interesa es que tu software funcione bien y cumpla con todas sus expectativas.Claro está que se puede obtener opiniones sobre la interfaz de usuario y otros,pero eso no implica a que me obliguen a utilizar un diseño de la BD:eek:, al contrario es más bien el programador o diseñador de la base de datos quien debe diseñar bien el modelo de la BD para que la información esté bien estructurada.;)
Bueno es sólo una opinion personal..espero que nadie se sienta ofendido...:D

Sobre lo comentado por ...
Eso quiere decir, mi amigo AzidRain que la relacion entre la tabla Factura y Recibo(como lo llamas tú) tienen cardinalidad N:M ;) por lo tanto segun el "Modelo Entidad Relación" no es necesario incluir en tu tabla factura ningun campo foraneo hacia la tabla Recibo, pues por que ya se tiene dicha información en tu tabla det_recibo; de otra forma la información en la BD tendría mucha redundancia y tu tabla det_recibo no serviría de nada o estaría por demás;)
Lo que veo es que definas bien la cardinalidad de la relacion entre la tabla "Factura" y "Recibo" y de ahí veas que cosas estan por demás y que cosa nuevas deben agregarse.
Saludos...:)

Realmente creo que el compañero AzidRain nos ha dado la información a cuenta gotas. Cosa extraña, viniendo de él.

También cabe la posibilidad de que no estemos entendiendo nada de lo que dice. Cosa rara, viniendo de nosotros :p

Ja, ja. Fuera de bromas, en principio estoy de acuerdo contigo, rgstuamigo, y es justo lo que yo le decía: o se tiene una relación muchos-muchos (en cuyo caso se requiere una tabla asociativa) o una relación 1-muchos (en cuyo caso se incluye la llave foránea en una de las tablas).

Sin embargo, si vemos su mensaje #6, supongo, sólo supongo, que la relación entre recibos y facturas realmente es muchos-muchos, pero, restringiendo a recibos activos en realidad es 1-muchos. O sea, una factura sólo puede estar en un recibo activo. Cosa que, en verdad, dijo desde un principio. Así que, el campo num_recibo en la tabla facturas sería algo así como num_recibo_activo. Con este peqeño cambio de nomenclatura creo que la cosa queda más clara.

Aún así, no deja de sorprender que la relación recibos-factura sea muchos-muchos.

// Saludos

Ahora si me han hecho reir, es cierto que tengo algo de tiempo ya en esto, pero también es cierto que por muchos años que uno tenga en una disciplina nunca termina uno de aprender y más en este ambiente donde te despiertas usando una tecnología y te duermes aprendiendo una nueva.

Quisiera aclarar que no es que el cliente haya metido las narices en las "tripas" de la aplicación o el diseño de la base de datos, sino que su modelo de negocio "es así" como lo describí y ya saben como son algunos clientes en este medio que piensan que solo ellos saben como manejar su negocio. Lo que dice Nuño por otro lado es muy cierto, a todos nos ha pasado eso y a fuerza de corajes poco a poco hemos ido puliendo esos detalles. Aquí en el changarro por ejemplo ya no cotizamos nada hasta que el cliente no nos diga todo lo que quiere o necesita y se le deja muy claro que cualquier cambio mayor respecto al funcionamiento del sistema requerirá cotización adicional. Hasta ahora ha funcionado.

En efecto al final es como dice Román, cabe mencionarles que nos metimos en estas honduras precisamente al revisar trabajo hecho anteriormente, de hecho el sistema está en producción ya desde hace varios meses y funciona como estaba planeado pero seguramente a algunos les ha pasado que al revisar ya sin presión ni nada código y diseño siempre encuentra uno cosas que mejorar. En este caso quizá ya no se toque este sistema pero si queremos sacar algo en firme para próximos desarrollos.

Finalmente acoto lo que dice Román. En efecto, una factura solo puede incluirse en un recibo activo a la vez, pero una vez que ese recibo se "cierra" o se "inactiva" puede volver a incluirse en otro. Los recibos anteriores se mantienen como historial por si se quiere saber cuantas veces ha salido una factura a cobro. De ahi que la relación al final sea muchos-muchos.

Saludos y gracias por todas las aportaciones