Sobre diseño de BD

[marcos1979]

Hola gente, quiero hacer una pregunta relacionada con el diseño de una BD. Supongamos que es para un punto de venta (de lo que sea) y simplificando para el ejemplo tengo una tabla Articulos (id_articulo, nombre, importe), otra Clientes (id_cliente, nombre...) y una Ventas (fecha, factura, cantidad, id_articulo {hace referencia a la tabla articulos}, id_cliente {hace referencia a la tabla clientes}). La duda es que si despues de insertar un registro en la tabla Ventas, edito cualquiera de las otras tablas, se modificaria la informacion de la Venta.
Lo que se me ocurre sería, o bien ademas de hacer referencia al articulo y al cliente, guardar la informacion completa en la tabla ventas (nombre e importe del articulo y nombre del cliente), esto no me parece muy eficiente. Otra idea sería que, en lugar de editar un registro, lo "marque" como "no activo" usando un campo mas e inserte un nuevo registro con los nuevos datos, claro que deberia usar algun tipo de "identificador" para poder, por ejemplo, saber cuantas unidades del artículo X vendi. El problema es que si el usuario se pone a "jugar" con la edicion se van a insertar muchos registros inútiles. Bueno, esta es mas o menos mi duda, como sería la mejor forma de diseñar la BD?

Un saludo

[Developer9]

Hay tablas y casos... hay tablas que se las denomina tablas fuertes, estas son tablas maestras y padres (mas adelante explicaré lo de padre), tambien existen tablas debiles o tablas transaccionales, o tablas hijas, estas se nutren de las tablas padres.

En tu caso una venta tiene un cliente y un articulo (aunque en la practica tiene mas datos de este tipo) y claro que si modificamos la tabla de clientes y articulos nuestra venta cambiaría. Desde el punto de vista de la base de datos se puede cambiar pero no se debería, las medidas se toman desde el punto de vista del lado de la aplicación que guarda las ventas. Todo se modulariza, deberías de tener un módulo de ventas y un modulo "general" por decirlo así, en el modulo general debes de tener las pantallas que te permiten ingresar, modificar y eliminar registros de las tablas de clientes y articulos (aunque en el caso de articulos deberías de tener un modulo de Inventario que maneje esto) y el acceso a dichas pantallas deben tener permisos de acceso según el usuario, el cual tiene un rol, y dicho rol tiene privilegios de acceso, ya que el usuario que registra la venta no podría modificar los datos de los clientes, pero un usuario administrador si, o por ejemplo si la aplicación corre en internet un usuario podría modificar sus datos, pero no podría ingresar una venta por ejemplo.

Los clientes tienen datos que podrían cambiar con el transcurso del tiempo, por lo que sí debería de ser permitido modificar sus datos, datos como su direccion, telefono, si es Contribuyente especial, los días de que se le da credito, si se le quita el crédito, su email... pero puede llegar a ser raro cambiarle el nombre, a menos que se lo haya ingresado mal. Y los datos antes mencionados no podrían ser cambiados por el usuario del sistema que registra las ventas sinó por otro, un administrador

En la tabla de ventas no es buena práctica guardar descripciones de los articulos ni de los clientes, sino simplemente el id que se transformaría en clave foránea. El acceso al resto de tablas se da para los usuarios que tengan los privilegios correspondientes... ya que estos no se van a poner a jugar con las descripciones.

Todo responde a roles y privilegios de acceso

[marcos1979]

Tu respuesta es muy clara pero en este caso, y no lo aclaré, es para una aplicacion sencilla donde hay un unico usuario (es para una pequeña industria, hasta el momento lo haria con access o MySQL y VB6)
Entiendo que no es comun modificar el nombre de un cliente o de un articulo pero si el importe/valor del articulo y aca es donde no se como se hace ya que, de modificarlo, modificaria tambien la venta.
Como debo solucionar eso???

Gracias y un saludo

[Developer9]

En tal caso, lo que podrías hacer es que tu aplicación solo permita modificar el importe y la descripción no. Para ayudarte en eso me tendrías que mostrar el código que estás utilizando

[PequeñoMauro]

Hola, yo le agregaria dos tablas:
Factura y Detalle_Factura (o nombres análogos), ya que si llevas el precio en la tabla articulo y lo modificas, modificas todas tus ventas.
En la tabla detalle pondrias la cantidad, precio y monto total.
Es mi sugerencia, ya que por detalle y factura tendrias un precio especifico y te serviria si deseas realizar reportes de ventas anteriores, etc....
Saludos

[marcos1979]

Lo de utilizar dos tablas como dice PequeñoMauro es como lo haría (para simplificar fue omitido en el ejemplo planteado)
Tambien estaria la posibilidad de editar solo el importe... pero que pasaria si el usuario se da cuenta que escribio mal el nombre (del articulo o del cliente, por ej.) despues de haber facturado??? Tendria que editarlo, o borrarlo y crear uno nuevo. Y el Stock (o el estado de cuenta del cliente) que se llevaba hasta el momento? Por eso me queria saber si hay alguna forma "estandar" de solucionar esto.
Se me ocurre esto aunque no se que resultado daria en cuanto a rendimientos:
La tabla ARTICULOS tiene un campo id autonumerico, uno nombre, uno importe, otro llamado esta_activo de tipo byte o booleano y uno mas que identifica el articulo llamado id_articulo.
Al insertar un nuevo articulo se le asigna un valor a id_articulo igual al valor maximo de ese campo + 1 y se "marca" esta_activo a True. Cuando se edita, se marca esta_activo a False, se ingresa un nuevo registro con los nuevos datos y en el campo id_articulo se coloca el mismo valor que tenia el registro que se "editó". Con esto tendria una forma de referirme al mismo articulo por mas que cambie cualquiera de sus campos utilizando el valor de id_articulo. A su vez nunca se modificaria una factura emitida ya que NUNCA se editan los datos del articulo, solo si esta o no activo. Lo mismo se podria aplicar a clientes, claro que no se la efectividad de este metodo ni el rendimiento, asi como tampoco cuan fácil es recuperar los datos de las tablas asi diseñadas.

Espero sus opiniones, un gran saludo y gracias.

[PequeñoMauro]

Hola marcos1979:
El usuario no deberia editar mal el producto, ya que no lo deberia editar, solo lo deberia escoger de una lista ya establecida. Puedes crearte un formulario en el cual ingresas los productos existentes, y ahi ingresas los productos que tienes, si gustas código autogenerado o de acuerdo a su descripción, criterio tuyo.
En la venta el usuario solo deberia escoger el producto que vende. Creo que la opción posterior que comentas haria que exista mucha redundancia en tu BD.
Debes plantear bien como será el modelo de tu BD de acuerdo a lo que necesitaras...
Saludos

[marcos1979]

Eso sería una vez agregado el producto, el cliente, etc. El problema es cuando fue mal ingresado por primera vez, despues si se procede a seleccionarlo de una lista como vos bien decis.
Pero que pasaría si, al ingresar los datos del cliente se lo hace mal, luego se realiza una venta y el cliente, una vez recibida la factura, informa que sus datos están mal, hay que corregir esa informacion pero la venta ya fue registrada. Si creo un nuevo cliente no me sirve por que en realidad es el mismo, si lo edito y miro las facturas registradas con las impresas no coinciden. No se si me explico bien?


Un saludo