¿Que enfoque de programación utilizarias?

[Ñuño Martínez]

Empezado por AzidRain

Coincido con la engorrosidad que mencionan varios compañeros pero ni hablar, así lo quiere el cliente, (...)

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.

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

[rgstuamigo]

Pues a mí me sorprende todo ésto... aunque no tengo demasiada experiencia en creaciones de software como la que tiene nuestro amigo AzidRain, 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?.
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, 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...

Sobre lo comentado por ...

Empezado por AzidRain

... 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.

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...

[roman]

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

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

[[AzidRain]]

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