Diseño/ejecución maestro/detalle
 

Hola a todos.

Actualmente estoy enfrascado en un programa con tablas maestro detalle, ya tuve algún problema con claves foráneas que quedó solucionado con la ayuda de algunos foreros (hilo http://www.clubdelphi.com/foros/showthread.php?t=41997).

Según he etado leyendo sobre diseño de Bases de Datos, en teoría, si no entendí mal, un diseño de tablas maestro-detalle como el que describo a continación sería correcto.

Código SQL [-]
  CREATE TABLE VENTAS (
       ID INTEGER NOT NULL,
       IDCLI INTEGER NOT NULL,
       FECHA DATE
  );
  
  CREATE TABLE LINEAS (
       IDVENTA INTEGER NOT NULL,
       LINEA INTEGER NOT NULL, 
       REFERENCIA VARCHAR(10), 
       DESCRIPCION VARCHAR(20), 
       CANTIDAD FLOAT, 
       IMPORTE FLOAT
  );
  
 ALTER TABLE MASTER ADD CONSTRAINT PK_VENTAS PRIMARY KEY (ID);
 ALTER TABLE LINEAS ADD CONSTRAINT PK_LINEAS PRIMARY KEY (IDVENTA, LINEA);
 ALTER TABLE LINEAS ADD CONSTRAINT RELATION_200 FOREIGN KEY (IDVENTA) REFERENCES VENTAS (ID);

El campo ID de VENTAS hace las veces de número de factura / albarán / pedido o similar, por lo que su asignación estaría reservada para el final, al momento que se acepta la venta, en el momento del commit, ya que si se asigna al inicio y la venta no es aceptada, pueden quedar huecos en el número de VENTA asignado si hay otras ventas simultáneas (no sé si me explico bien :o).

Las dudas que me corroen son:

a) si ID = NULL hasta el final, se producirán errores en la inserción de lineas detalle FOREING KEY

b) puedo poner ID = 0 y al final actualizarlo, no queda muy elegante, pero ¿como actualizo el detalle si ambas consultas están enlazadas por ID?, para realizar esto último ¿habría que desvincular las consultas?, ¿actualización en cascada?

c) o en todo caso debería trabajar con controles no asociados a datos y sustituir el DBGrid del detalle por un TStringGrid y al finalizar volcar todo a la BD. ¿Es practico teniendo en cuenta que pueden haber 2, 20 ó 100 líneas (por exagerar un poco)?

d) el diseño de las tablas es incorrecto:confused::confused::confused:

No sé como actuar, ¿qué opciones utilizais en éstos casos?:confused:

Gracias

Eterno dilema
 

Hola.

Efectivamente, el diseño que planteas te puede traer algunos dolores de cabeza. Te podría contestar una a una tus dudas, pero mejor te digo el método que utilizo y menos problemas me ha dado.
Atendiendo a las reglas de ingeniería del software, cada tupla (registro) de una tabla debe tener un identificador único (preferiblemente integer), que deberá ser su clave primaria. Es no quiere decir que no puedas tener otras claves únicas.

Te propongo esta estructura:

Código SQL [-]
CREATE TABLE VENTAS (
       ID                        INTEGER NOT NULL,
       NUMERO_DOCUMENTO  INTEGER NOT NULL
       IDCLIENTE             INTEGER NOT NULL,
       FECHA DATE
  );
  
  CREATE TABLE LINEAS (
       ID                        INTEGER NOT NULL
       IDVENTA               INTEGER NOT NULL,
       LINEA                   INTEGER NOT NULL, 
       REFERENCIA          VARCHAR(10), 
       DESCRIPCION        VARCHAR(20), 
       CANTIDAD             FLOAT, 
       IMPORTE               FLOAT
  );
  
 ALTER TABLE VENTAS ADD CONSTRAINT PK_VENTAS PRIMARY KEY (ID);
 ALTER TABLE LINEAS ADD CONSTRAINT PK_LINEAS PRIMARY KEY (ID);
 
CREATE UNIQUE INDEX IDX_LINEAS1 ON LINEAS (IDVENTA, LINEA);
 
 ALTER TABLE LINEAS ADD CONSTRAINT RELATION_200 FOREIGN KEY (IDVENTA) REFERENCES VENTAS (ID);

También crearía unos GENERATOR para los ID de cada tabla, pero eso ya como tú prefieras. La manera de programar sería la siguiente:

Dar de alta el registro de cabecera (maestro) y generar un identificador único para esa cabecera, sin importarte si se deja el hueco o no por cancelación. Abrir la tabla de detalles en modo Cache o bajo una transacción, y asignar al IDVENTAS el ID generado del Maestro en cada alta en Detalle. Antes de confirmar la venta, sacar el número consecutivo para el campo NUMERO_DOCUMENTO según el tipo de documento (según has comentado) y actualizar dicho contador.
Trabajarás con 'códigos internos' de manera que el nº de factura o pedido se genera cuando se confirme la entrada. Además cuentas con la ventaja de poder realizar fácilmente cambios en la numeración de facturas/albaranes, ya que dicha renumeración no afecta a los detalles.

También es bueno que los detalles tengan un identificador único por si luego tienes que hacer referencia a alguna línea de detalles, por ejemplo, para enlazar lineas de albaranes de compra con las líneas de pedidos a proveedores. Si usas claves compuestas terminas teniendo que crear un chorro de campos cada vez que quieres enlazar un registro con otro.

Saludos.

Gracias afxe por tu respuesta.

Le he estado dando vueltas al "problemilla", teniendo en cuenta las opciones expuestas y también consideré la posibilidad de implementar algún tipo de tabla temporal al efecto ... posiblemente la solución que planteas es la más sencilla de todas a nivel de implementación en BD y a la hora de programarla ...

Si .. lo haré de la manera que indicas, gracias :):)