Muchas gracias! :) saqué muchas cosas, de verdad.
Cita: Si. por desgracia todo sistema que idees en teoría o en papel, nunca se transfiere de un modo fácil, porque lo que no es fácil es la realidad.
Claro, el clásico "un sistema de stock es fácil, vendés y restas" pero también se puede descontar porque son materiales que se usan, que se devuelven, etc. todo depende, stock de una libreria, de un taller, de un restaurante, etc y a qué nivel de registro se quiera llegar je y "un sistema de stock es fácil, vendés y restas" ya deja de ser tan fácil.
Cita: Volviendo al tema de los productos, que al final no te comenté del todo, la idea central es que todo lo que se provee a un cliente es, conceptualmente, un producto. En ese sentido son productos los servicios contratados, los aparatos vendidos, los accesorios, pero también son productos el soporte técnico provisto, los asesoramientos on-line, y cualquier acción que pueda representar un item legalmente facturable.
¿Se entiende la idea?
Entiendo que un producto facturable o un "algo" que corresponde a un item no es solamente un objeto tangible, también puede ser un servicio u otra cosa que se facture, bonificaciones, cargos, etc.
Cosas que se pueden facturar
1. Productos (teléfono celular, teléfono inalámbrico, un router)
3. Servicios (Internet, Telefonía fija y móvil, reparación, asistencias)
4. Cargos (pago por mora, reconexión)
5. Bonificaciones (por algo mal cobrado, por días sin servicio)
Todos estos (y ni me imagino que más tiene una empresa grande) son tipos de cosas que se puede facturar.
Cita: En ese sentido, lo que tienes es una estructura de herencia, semejante a la de clases en POO, pero que se implementa de un modo algo distinto en una BBDD relaiconal.
Como cada "producto" de diferente tipo reconocible, representa una entidad que hereda de una entidad superior (Producto), existirán unos pocos atributos propios de esa entidad, y unos muchos que dependerán de la entidad hija (entidad débil).
Ahora bien, en POO este esquema implica que se instancia una entidad hija, pero no la entidad padre (superior), porque en programación no se instancian las clases abstractas, como "Producto", sino "ProductoServicio", "ProductoTeléfono", "ProductoLinea".
Pero cuando pasas a la base de datos, la cosa cambia: Para que se pueda crear un registro de ProductoTelefono, debe crearse primero un registro en Producto, porque la PK en Producto es la PK que el ProductoTelefono hereda al ser la que determina la dependencia del registro en esa tabla respecto al Producto.
¿Se entiende?
Sisi entiendo que es diferente, no voy a pensar en poo o en comparar un diagrama de clases con el esquema de una base de datos
Cita: Ahora bien, ¿¿Como se llega de tener N tipos de productos de varias clases diferentes, a una única fctura?
En realidad es sencillo, y complicado al mismo tiempo:
- Las facturas no se relacionan directamente con cada tabla hija, sino con la tabla padre.
- La tabla padre debe tener un atributo o flag que determine de qué tipo de producto se trata.
- Según el tipo de producto, los stored procedures generan la lectura de la tabla correspondiente a ese o esos items.
- En la propia tabla o en la lógica del Sp se incluye el considerar si es un item de cobrar, de impuesto o de bonificación o beneficios.
- Es muy habitual que en realidad lo que se haga es un único query que, por medio de un UNION ALL, condicionado en base a algunos criterios en cada subselect, genere en una sola llamada toda la lista de importes de los items de la factura.
A la factura le interesa sus item. A cada item le interesa el artículo y no las características o tipos. El artículo es quien debe armarse bien con sus datos para que pueda ser un item facturable y a su vez la factura pueda confeccionarse correctamente.
¿es eso?
Lo que pienso es:
Primero se comienza en sistema para un negocio que vende teléfonos y quiere un sistema de facturación. Como para estar preparado al cambio y al crecimiento de la empresa no hay que pensar en un sistema de facturación para teléfonos, sino en facturar artículos. Que artículo abarque un teléfono celular o una reparación, por más que la empresa no se dedique a la reparación de celulares, en un futuro lo querrán ofrecer y no habrá inconvenientes, ni siquiera si implementan servicio de telefonía.
Entonces si hago facturación para celulares:
ItemsFacturas>Telefonos
Si quiero agregar reparaciones, tendría que agregar una tabla "Reparaciones" y tendría que modificar ItemsFacturas y agrega otras tablas más.
Si hago para articulos
ItemsFacturas>Articulo>Telefono
Un teléfono es un artículo que se factura y cualquier cosa que se factura va a ser un artículo. Por lo tanto, si quiero empezar a facturar las reparaciones no tendría que modificar la estructura.
Ahí es como entiendo lo que dices de: "Según el tipo de producto, los stored procedures generan la lectura de la tabla correspondiente a ese o esos items."
Artículo puede ser de tipo "Teléfono" o "Reparación". Ahora también podría pensar en reparación, es un servicio
Al menos eso entendí de lo que dices de abstraer al menos una capa
Cita: La idea de esto es abstraer todo una capa mas al menos, cosa que cuando se emita la factura, la clasificación del producto por categorización, permita al stored procedure (si, se necesitarán para eso), reconstruir la logica de cada item de modo más coherente y consistente.
Me queda esto:
