Ir al contenido


Foto

Como organizar tabla con mas de 1 relacion.


  • Por favor identifícate para responder
6 respuestas en este tema

#1 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 13 abril 2015 - 07:23

Tengo en mi sistema una tabla cheques. Un cheque puede venir de un cliente, o puede ir o venir de un proveedor.

 

Pense poner el idproveedor y el idcliente en la tabla cheques, pero quedara un idvacio y uno lleno.

 

De lo contrario deberia tener una tabla (clicheque)que contega idcliente e idcheque, y otra(proveecheque) idproveedor e idcheque pero como realizo la busqueda, el filtrado? El filtrado seria seleccionar de la tabla  clicheque o proveecheque segun se necesite.

 

Y la busqueda de un cheque? Debo buscar en ambas tablas para saber de donde proviene o que se hizo? Es correcto este modelo o que me aconsejan?

 

Saludos


  • 0

#2 Fenareth

Fenareth

    Advanced Member

  • Administrador
  • 3.486 mensajes
  • LocationMexico City

Escrito 13 abril 2015 - 08:42

Yo lo que haría es una tabla que contuviera éstos campos de control: numero_cheque, tipo_cheque (cliente o proveedor), tipo_movimiento (cheque de entrada o cheque de salida) e id_persona (donde se coloca el id del cliente o del proveedor según el tipo definido en el campo tipo_cheque)...

 

Adicionales claro los campos de importe, fecha y el resto de los obvios

 

Yo creo que eso te permitiría un adecuado control de los movimientos de tus cheques y se resolvería tu problema de búsquedas y filtrados... (y)

 

Saludox ! :)


  • 1

#3 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 13 abril 2015 - 09:29

Apoyo la idea de Fenareth,

Como TIP: cuando uno detecta que 2 o más entidades comparten características similares, es porque hay una abstracción que está por encima de ésta. Ergo: la información o datos que pueden ser comunes a éstas es conveniente que estén en una tabla que la represente...

 

El equivalente en el campo OO diríamos que descubrimos la clase abstracta común a dos clases. Es como decir que tanto el perro como el gato son cuadrúpedos. Para el caso Clientes vs Proveedor ambos pueden comportarse como empresa. Luego esta tabla debe tener los campos o atributos que te permita llevar la distinción entre cada uno. Luego, si hay información particular o específica a cada uno puede considerarse alguna tabla adicional o bien reestructurar el problema.

 

Cuando se debe trabajar con un caso abstracto, independiente de si es por ejemplo Cliente o Proveedor... cantado que hay algo más que no vemos: tablas/clases abstractas.

 

Saludos,


  • 0

#4 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 13 abril 2015 - 09:54

Claro, pero el cheque es una entidad u objeto que puede asociarse a un cliente o proveedor. La idea de Fenareth es buena porque si el tipo es cliente voy con el idpersona a la tabla clientes, y si es de tipo proveedor a la tabla proveedor. De hecho tengo una tabla maestra persona(deberia ser razon social) puede contener personas o empresas, sean clientes proveedores o empleados. Creo que lo que me obstaculizo es como acceder a los datos. y un cheque puede pertenecer a un solo cliente a la vez o aun solo proveedor a la vez, osea que con tener el tipo y el idpersona es suficiente.

 

Muchas gracias...


  • 0

#5 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 14 abril 2015 - 02:55

Yo lo que haría es una tabla que contuviera éstos campos de control: numero_cheque, tipo_cheque (cliente o proveedor), tipo_movimiento (cheque de entrada o cheque de salida) e id_persona (donde se coloca el id del cliente o del proveedor según el tipo definido en el campo tipo_cheque)...

 

Adicionales claro los campos de importe, fecha y el resto de los obvios

 

Yo creo que eso te permitiría un adecuado control de los movimientos de tus cheques y se resolvería tu problema de búsquedas y filtrados... (y)

 

Saludox ! :)

Lo que se me ocurre ahora es como puedo representar que un cheque fue recibido por parte de un cliente y entregado a un proveedor? necesito 2 idpersona? y esto no es posible.

 

Por eso crearia las tablas clicheque y provecheque como mencione en el primer mensaje.

 

Tambien podria plantear que los proveedores forman parte del sistema de compras y podria registrar una compra con el proveedor, etc, y luego una tabla de relacion de esa compra con los cheques que se asociaron, es lo mismo que se hace con los productos : la tabla compra tiene idproveedor fecha,etc y en otra de relacion todos los productos de esa compra(para no repetir todo el registro de compra)


sql
  1. CREATE TABLE cheque(
  2. idcheque INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  3. idcliente INT,
  4. numero INT,
  5. fecharecibo DATE,
  6. fechacobro DATE,
  7. importe DECIMAL(10,2),
  8. titular VARCHAR(100),
  9. cuenta INT,
  10. CUIT INT,
  11. haber DECIMAL(10,2),
  12. cobrado bool,
  13. fechadecobro DATE,
  14. tipo CHAR,
  15. idpersona INT,
  16. );

create table factura(
idfactura int not null auto_increment primary key,
monto decimal(10,2),
idproveedor int,
tipo char,
foreign key (idproveedor) references proveedor(idproveedor) on delete no action
);
create table compras(
idcompra int not null auto_increment primary key,
idfactura int,
cantidad decimal(10,2),
idproducto int,
preciou decimal(10,2),
foreign key (idproducto) references producto(idproducto) on delete no action,
foreign key (idfactura) references factura(idfactura) on delete cascade
);

Una vez teniendo la factura se registra por cada producto de la compra o factura cantidad idproducto preciou.

 

Entonces los cheque asociados que pueden ser varios:


sql
  1. CREATE TABLE chequecompra(
  2. idfactura INT,
  3. idcheque INT,
  4. FOREIGN KEY (idfactura) REFERENCES factura(idfactura),
  5. FOREIGN KEY (idcheque) REFERENCES cheque(idcheque)
  6. );

lo mismo haria para las ventas a los clientes, de la tabla ventas asociar idcheque.

 

Saludos


  • 0

#6 Agustin Ortu

Agustin Ortu

    Advanced Member

  • Moderadores
  • PipPipPip
  • 831 mensajes
  • LocationArgentina

Escrito 15 abril 2015 - 10:35

El tema esta interesante

 

Si no me falla la memoria, en este caso la jerarquia la podes resolver de 3 maneras distintas:

 

1) Se eliminan las entidades derivadas del modelo (ChequesClientes, ChequesProveedores) y se colocan todos sus atributos en el ancestro, dichos atributos deberan ser todos no obligatorios

 

2) Se elimina el ancestro del modelo (Cheques) y se colocan todos los atributos de cheques en cada una de las entidades derivadas (teniendo en cuenta que Cheques tiene los atributos en comun)

 

3) Se dejan las 3 entidades en el modelo. Para conocer los datos de un Cheque, hará falta hacer un JOIN con la entidad especializada. Este JOIN te daria como resultado una tabla temporal igual a las que se definen en el punto 2

 

Como yo veo las cosas, la opcion del punto 1 es la que menor claridad aporta al modelo, pero a pesar de eso es la mas rapida para trabajar, ya que no requiere JOINS. Por ejemplo si tenes que listar todos los cheques en un determinado rango de tiempo sin importar su tipo, basta con un SELECT en la tabla Cheques

 

La opcion del punto 2, organiza un poco mas las cosas separando en dos tablas distintas segun el tipo de cheque (Cliente o Proveedor). El problema en este caso es la clave primaria. Si cada tabla mantiene su propia clave, implica tener una relacion en la que tenes que agregar un atributo extra, el tipo de cheque. En el caso anterior, cada cheque tendria su propio Id (asumiento que usaras clave primaria artificial, que obtendrias a traves de un generador)

 

La opcion del punto 3, es la mas clara de todas, ya que cumple con la filosofia del modeo ER y representa de manera mas comprensible y abstracta la base de datos, solucionando ademas el problema de la opcion 2, ya que la tabla que se va a encargar de generar el Id para el cheque es justamente la tabla Cheques. Las tablas especializadas lo unico que hacen es agregar mas informacion a la que tenes en la tabla padre. Esta opcion tiene el inconveniente de que es la mas compleja de manejar, las operaciones CRUD (inserciones, eliminaciones, seleccion y actualizacion) son mas dificiles de implementar y tambien mas costosas en terminos de performance

 

Saludos


  • 1

#7 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 16 abril 2015 - 01:13

El tema esta interesante

 

Si no me falla la memoria, en este caso la jerarquia la podes resolver de 3 maneras distintas:

 

1) Se eliminan las entidades derivadas del modelo (ChequesClientes, ChequesProveedores) y se colocan todos sus atributos en el ancestro, dichos atributos deberan ser todos no obligatorios

 

2) Se elimina el ancestro del modelo (Cheques) y se colocan todos los atributos de cheques en cada una de las entidades derivadas (teniendo en cuenta que Cheques tiene los atributos en comun)

 

3) Se dejan las 3 entidades en el modelo. Para conocer los datos de un Cheque, hará falta hacer un JOIN con la entidad especializada. Este JOIN te daria como resultado una tabla temporal igual a las que se definen en el punto 2

 

Como yo veo las cosas, la opcion del punto 1 es la que menor claridad aporta al modelo, pero a pesar de eso es la mas rapida para trabajar, ya que no requiere JOINS. Por ejemplo si tenes que listar todos los cheques en un determinado rango de tiempo sin importar su tipo, basta con un SELECT en la tabla Cheques

 

La opcion del punto 2, organiza un poco mas las cosas separando en dos tablas distintas segun el tipo de cheque (Cliente o Proveedor). El problema en este caso es la clave primaria. Si cada tabla mantiene su propia clave, implica tener una relacion en la que tenes que agregar un atributo extra, el tipo de cheque. En el caso anterior, cada cheque tendria su propio Id (asumiento que usaras clave primaria artificial, que obtendrias a traves de un generador)

 

La opcion del punto 3, es la mas clara de todas, ya que cumple con la filosofia del modeo ER y representa de manera mas comprensible y abstracta la base de datos, solucionando ademas el problema de la opcion 2, ya que la tabla que se va a encargar de generar el Id para el cheque es justamente la tabla Cheques. Las tablas especializadas lo unico que hacen es agregar mas informacion a la que tenes en la tabla padre. Esta opcion tiene el inconveniente de que es la mas compleja de manejar, las operaciones CRUD (inserciones, eliminaciones, seleccion y actualizacion) son mas dificiles de implementar y tambien mas costosas en terminos de performance

 

Saludos

Muchas gracias por responder. tambien pense que un cheque siempre vendra de un cliente, porque es el que paga. Pero ya me dejaste una idea mas clara del tema..


  • 0




IP.Board spam blocked by CleanTalk.