[SOLUCIONADO] [CONSULTA] Sobre Diseño.

[NLeone]

Estimados, gracias de antemano por tomar el tiempo de leer mi consulta, es una duda bastante sencilla para quienes hayan desarrollado algún Sistema de Venta.

Tengo 3 Tablas:

persona_fisica:

id
cuil
apellido_paterno
apellido_materno
nombre_s
...

persona_juridica:

id
cuit
ingresos_brutos
razon_social
inicio_actividades
...

cliente:
id
...
...

El tema es que el Cliente puede ser tanto persona física como persona jurídica, y no se cómo realizar la relación con alguna de las dos tablas, la idea es tener integridad referencial, he hecho con otro sistema lo mismo pero no tenía clientes, sino afiliados, y en ese caso no tuve drama ya que solo podían ser personas físicas.

Se me ocurrió crear 2 tablas clientes, una para cada persona y luego unirlas en las consultas, pero también me modificaría el tema de las facturas, ya que en la tabla para las mismas, traigo los datos de la tabla cliente....

Otra posibilidad es de en la tabla cliente, en vez de poner una FK de alguna de las dos tablas (persona física o persona jurídica), poner el cuil/cuit, y que sea único en la tabla, pero no me da seguridad para la integridad referencial.

Bueno aguardo alguna respuesta y agradezco nuevamente!

Saludos!

[Libras]

tabla cliente con su datos y un id_tipo, tabla fisica con el id_cliente y los datos especiales para esta caracteristica, tabla juridica id_cliente y los datos especiales para esta caracteristica, y la tabla de tipo_persona

[NLeone]

Iniciado por Libras

tabla cliente con su datos y un id_tipo, tabla fisica con el id_cliente y los datos especiales para esta caracteristica, tabla juridica id_cliente y los datos especiales para esta caracteristica, y la tabla de tipo_persona

Hola Libras! Gracias por tu respuesta, pero perdón, no entiendo bien lo que sugieres. Por lo que veo dices que en la tabla cliente vaya un campo id_tipo, entiendo esto para que sea para la persona fisica y juridica. Por otro lado en la fisica el id_cliente, pero el problema es que no todas las personas fisicas son clientes, sino que algunas pueden serlo, como también pueden ser empleados, etc. Entonces no puede ir un campo id_cliente ni en persona fisica ni en juridica, porque las juridicas no siempre son clientes, sino que pueden llegar a serlo. También pueden ser empleadores, proveedores pero no clientes.

Es como en la vida real, en cualquier organización existen personas juridicas y fisicas y de ahí parte todo.

Lo que no se es lo que cuento antes, como hacer que en una sola tabla clientes puede haber alguno de los dos, manteniendo la integridad referencial y la clave foranea en cascada...

Gracias!

[Libras]

entonces que no sea el id_cliente, que sea el id_tipo, como lo llames es lo de menos, lo que te sugiero es que tengas una tabla de tipos para que puedas distinguir cada uno de los elementos de tu sistema

[NLeone]

Iniciado por Libras

entonces que no sea el id_cliente, que sea el id_tipo, como lo llames es lo de menos, lo que te sugiero es que tengas una tabla de tipos para que puedas distinguir cada uno de los elementos de tu sistema

Gracias nuevamente!

Entiendo lo que dices. Ahora a ver si paso en limpio:

Tengo persona fisica y persona jurídica y también la tabla cliente. En esta última pongo un campo id_tipo para especificar el mismo. Pero mi problemática está en cómo mantener integridad referencial. Por ejemplo cómo hago para que las 2 tablas de persona f y persona j le provean su id como fk a la tabla cliente? Viene por ahí mi duda.

Gracias y saludos!

[Libras]

Si son 2 tablas donde vas a guardar id's diferentes, entonces no tienes porque guardar el id en las 2 tablas, a menos que crees una tabla con los datos que comparten fisicas y juridicas y sobre esta pongas el id, ya los datos que son "exclusivos de cada tabla" entonces esos nada mas les pones el id a los que les corresponda, podrias poner un pequeño esquema de tus tablas?

[NLeone]

Iniciado por Libras

Si son 2 tablas donde vas a guardar id's diferentes, entonces no tienes porque guardar el id en las 2 tablas, a menos que crees una tabla con los datos que comparten fisicas y juridicas y sobre esta pongas el id, ya los datos que son "exclusivos de cada tabla" entonces esos nada mas les pones el id a los que les corresponda, podrias poner un pequeño esquema de tus tablas?

Gracias por tu respuesta Libras! Adjunto una captura de 4 tablas de mi base, hasta ahora es una base de 42 tablas pero en cuestión son estas 4. Creé una tabla para clientes fisicos y otros juridicos porque hasta el momento de consultar no me daba la idea de cómo hacer. Pero me trabé cuando hay que hacer las facturas, de donde toma el cliente la misma....en lo que es facturas no puedo tener varias tablas ya que deben ir numeradas.



Saludos!

[Libras]

Tienes 2 tablas con los mismos campos, eso esta mal para un modelo relacional, lo cual dice que tu base de datos no esta normalizada, ademas veo que tienes 8 campos repetidos en las tablas de persona_fisica, juridica,

las 2 tablas xlj_cliente_pf y xlj_cliente_pj, podrian quedar en una sola tabla usando los tipos que te menciono quedando

xlj_cliente
id
.....

Para persona fisica y juridica podriamos sacar una tabla para personas, con estos datos:

Personas
id
id_tipo
cuit
xlj_status_id
created_by
created_at
updated_by
updated_at
bloqueo
id_user_bloqueo
version


otra tabla para personas fisicas:

p_fisicas
id FK a personas con el id
num_documento
apellido
......

otra para personas juridicas
id FK a personas con el id
ingresos
razon
.....


Y por supuesto la tabla de tipos

Tipos
id_tipo
descripcion


Y al momento de hacer la factura, nada mas usarias el Id de la tabla personas, tienes el tipo para saber a que tipo corresponde

[NLeone]

Iniciado por Libras

Tienes 2 tablas con los mismos campos, eso esta mal para un modelo relacional, lo cual dice que tu base de datos no esta normalizada, ademas veo que tienes 8 campos repetidos en las tablas de persona_fisica, juridica,

las 2 tablas xlj_cliente_pf y xlj_cliente_pj, podrian quedar en una sola tabla usando los tipos que te menciono quedando

xlj_cliente
id
.....

Para persona fisica y juridica podriamos sacar una tabla para personas, con estos datos:

Personas
id
id_tipo
cuit
xlj_status_id
created_by
created_at
updated_by
updated_at
bloqueo
id_user_bloqueo
version


otra tabla para personas fisicas:

p_fisicas
id FK a personas con el id
num_documento
apellido
......

otra para personas juridicas
id FK a personas con el id
ingresos
razon
.....


Y por supuesto la tabla de tipos

Tipos
id_tipo
descripcion


Y al momento de hacer la factura, nada mas usarias el Id de la tabla personas, tienes el tipo para saber a que tipo corresponde

Libras! Entiendo lo que me dices. Es bueno el análisis, igualmente te cuento que esos campos:

xlj_status_id
created_by
created_at
updated_by
updated_at
bloqueo
id_user_bloqueo
version

Son de auditoria, son necesarios y requerimiento del cliente, y la base en general está normalizada, sino fijate en las relaciones con estado civil, genero, etc. Son fk de otras tablas que se han separado para que pueda estar normalizada.

Cada registro de la base de datos requiere de esos campos, por ejemplo version se utiliza para los bloqueos optimistas, lo trabajo con el framework Yii2 y ActiveRecord.

Pero ahora me cierra más y mejor el de poner una tabla principal PERSONA y de ahí relacionar las otras....

Muchas gracias!!!

[Libras]

Iniciado por NLeone

y la base en general está normalizada

No hasta tercera forma que es el standar para decir que tu base ya quedo normalizada :P que bien que ya minimo te di una idea de como seguir :D

[NLeone]

Iniciado por Libras

No hasta tercera forma que es el standar para decir que tu base ya quedo normalizada :P que bien que ya minimo te di una idea de como seguir :D

Si te entiendo....pero si saco esos campos quedará mejor normalizada pero perderé control de auditoria que me exige el cliente no?

[Libras]

No te dije que los saques, sino que los pongas en una sola tabla, no puse todos los campos porque la verdad me dio pereza escribir todo :P .... queria decir, todos los demas campos de la tabla ;) jejejejeje

[NLeone]

Iniciado por Libras

No hasta tercera forma que es el standar para decir que tu base ya quedo normalizada :P que bien que ya minimo te di una idea de como seguir :D

Iniciado por Libras

No te dije que los saques, sino que los pongas en una sola tabla, no puse todos los campos porque la verdad me dio pereza escribir todo :P .... queria decir, todos los demas campos de la tabla ;) jejejejeje

Jajajja, no ya entendí lo de separarlos, me refiero a los campos de auditoria:

xlj_status_id
created_by
created_at
updated_by
updated_at
bloqueo
id_user_bloqueo
version

Esos campos se repiten en todas las tablas para grabar los usuarios que crearon, modificaron y los momentos, por eso se repiten y hacen que no esté normalizada la base. Pero todo lo demás está bien separado en la base de datos.

Si no los pongo en todas las tablas, el cliente no sabrá quien realizó acciones sobre esos registros...

Te consulto en base a tu experiencia, ya que estoy dando mis primeros pasos y busco documentación, estudio y me nutro de la experiencia de otros colegas, si puedo ayudar a alguien también intento jajaja.

Saludos!

[Libras]

y porque mejor no haces una tabla para auditoria? donde tengas todos esos datos mas el nombre de la tabla ;) y listo te evitas el tener los mismos campos en cada tabla :P

[NLeone]

Iniciado por Libras

y porque mejor no haces una tabla para auditoria? donde tengas todos esos datos mas el nombre de la tabla ;) y listo te evitas el tener los mismos campos en cada tabla :P

Libras! Me gusta esa idea, nunca lo hice porque en las veces que vi ejemplos o estudié algún concepto lo vi hecho de esta manera, porque en realidad si te pones a pensar, el campo xlj_status_id es una FK de la tabla status que pueden ser varios, esto no se puede cambiar, luego, conceptualmente los campos created_by, created_at, updated_by y updated_at son de auditoria, no son atributos que pertenezcan a una tabla específica, desde la parte conceptual obvio. Pero técnicamente se repiten y hacen como bien decís las tablas no estén ni en le 3 forma normal...

Los campos id_user_bloqueo también es una FK así que no molesta, y el campo version, me lo obliga a poner el framework Yii2 para los bloqueos optimistas, ya que trae un método para poder controlar la versión de los registros.

Ahora mi consulta en base a lo que sugerís que me interesa mucho, es la siguiente:

Actualmente con la estructura como la tengo, con eventos del mismo framework que actúan como triggers de base de datos, pero son de aplicación, guarda automáticamente el usuario y la fecha con una expresión NOW, esos campos por cada INSERT o UPDATE.

Si lo hago como lo dices, deberé en cada uno de los métodos de INSERT o UPDATE insertar un registro en la tabla_auditoria, luego para recuperarlos en las vistas de la aplicación, deberé o unir los datos de las tablas o realizar joins no es así? este es óptimo para resultados de más de 500 o 1000 registros por página? Mi cliente necesita ver por cada persona quién la crea a qué hora y quién modifica un registro.

Bueno espero no haber abusado de tu tiempo.

Saludos y gracias nuevamente!

[Libras]

Eso es lo malo de usar los frameworks, que como todo viene ya "acomodado" no te da mucha oportunidad de cambiar lo que ya tienes, sobre esos temas de programacion realmente desconozco somo seria la mejor manera de optimizarlo, y sobre tu question de 500 o 1000 registros, eso es una nada para el manejador de base de datos :P.

Yo te estoy dando las recomendaciones basadas en mi experiencia como Administrador de bases de datos, ya si no se puede "normalizar" por algo del framework, pero funciona, no queda de otra mas que dejar asi la base de datos :p y mas si como dices que ocupas esos datos......

[NLeone]

Iniciado por Libras

Eso es lo malo de usar los frameworks, que como todo viene ya "acomodado" no te da mucha oportunidad de cambiar lo que ya tienes, sobre esos temas de programacion realmente desconozco somo seria la mejor manera de optimizarlo, y sobre tu question de 500 o 1000 registros, eso es una nada para el manejador de base de datos :P.

Yo te estoy dando las recomendaciones basadas en mi experiencia como Administrador de bases de datos, ya si no se puede "normalizar" por algo del framework, pero funciona, no queda de otra mas que dejar asi la base de datos :p y mas si como dices que ocupas esos datos......

Libras! Tienes mucha razón en lo que dices, y a veces es hacer un balance del costo / beneficio, pero bueno, la verdad es que estoy muy agradecido con cada una de tus respuestas, has dado tu tiempo en ayudarme y lo valoro ! Es lo bueno de pertenecer a comunidades de este tipo...

Te dejo un saludo y deseo un feliz 2017! voy a marcar el tema como solucionado para que no siga dando vueltas sin sentido!

Hasta la vuelta!