OT. Persona = cliente, proveedor, empleado.

[mpulla]

Buen día.

En mi db tengo tablas Proveedor, cliente, empleado con campos repetidos como Nombre, apellidos, dirección, teléfono que siendo la misma persona la data es redundante.

Ahora quiero normalizar

Entonces tendría:
Tabla Persona con datos PersonaId, Nombres, apellidos, dirección, teléfono, etc
Tabla Clientes ClienteId, PersonaId, Forma de Pago, Vendedor, lista de precio, cupo de crédito, etc.
Tabla Proveedores ProveedorId, PersonaId, Forma de Pago, cupo de credito, etc.

Ahora viene la lógica para el ingreso de datos, aquí necesito de su experiencia si tienen algún modelo, pantalla, comentario de como lo hacen se los agradezco de antemano.

Esto es lo que tengo pensado al momento.

Cuando llega un cliente nuevo reviso que la data no exista en la tabla persona y si existe que no sea cliente, si cumple con las condiciones debidas entonces ingreso los datos a las tablas correspondientes.

Luego esta misma persona va a ser  proveedor ya existe en la tabla persona pero no es proveedor entonces ingreso datos a la tabla proveedor.

El mismo caso se aplicaría si la persona pasaria a ser empleado de la empresa.

Saludos.
Mauricio

[Pablo Daniel Lissa]

Hola:

Me interesa lo que te vayan a responder Mauricio. Hace un tiempo, en mi lugar de trabajo empezamos un planteo similar. Al final no lo seguimos, porque se nos complicó un poco cuando empezamos a considerar, por ejemplo, que una empresa puede ser cliente. Entonces, la herencia con Persona ya era un poco forzada. Además, dentro de la jerarquía teníamos otras entidades como Usuarios del SIstema, huéspedes de hoteles, etc.

En su momento, lo que planeábamos era hacer pantallas con pestañas para esos datos comunes y otras pestañas para los datos particulares.

Éxitos. Saludos.
-------------------------------------------------------------------------------------------------------------------------------------

[FidelJ]

Yo utilizo tablas para Clientes, Proveedores, Empleados, Fleteros (que también son proveedores) y Socios.  

Todos tienen en común la clave única de identificación tributaria (CUIT). El diseño básico de las tablas es exactamente igual para denominación (ó apellido y nombres), calle, altura, ciudad, código postal, provincia,  país, etc. La información necesaria para cada caso tiene sus particularidades,  por lo que cada tabla tiene sus campos específicos. 

Ahora bien, a fin de poder importar los datos compartidos cuando se necesitan (cliente que se transforma en proveedor ó viceversa, empleado que también es cliente, etc.), utilizo una tabla mediadora, donde van a parar todas las altas y modificaciones de los datos comunes. Dicha tabla tiene la estructura básica igual que las tablas base y además los id que corresponden a cada tabla. Tiene un índice maestro por el número de Cuit ó Cuil de modo que no puedan repetirse. 

Una complicación surge con aquellos clientes que, en Argentina, la legislación fiscal obliga a identificarse pero no quieren aportar más que el número de documento. Por lo que es necesario calificar el campo CUIT con el tipo de documento (básicamente CUIT, DNI Y pasaporte). 

Cuando se ingresa el número y tipo de documento en el alta de cualquiera de los sujetos, el sistema consulta en la tabla unificada si existe y en el caso, trae al alta todos los datos básicos.

En las modificaciones de datos, cuando son pertinentes, se convoca a una rutina de actualización de la tabla unificada.

Igualmente utilizo un Id para cada tabla.

En algunos casos, por ejemplo para información requerida por la Afip, utilizo como base de la consulta la tabla unificada, de donde ya podemos saber si el sujeto en cuestión es Cliente, Proveedor, Empleado, Etc., y dirigir el procedimiento para averiguar las operaciones efectuadas en el sentido que fuere.

Saludos.

El miércoles, 10 de octubre de 2012 10:40:09 UTC-3, mpulla escribió:

[Víctor Hugo Espínola Domínguez]

Hola Mauricio

Interesantísimo el tema; teóricamente tu idea es correcta, pero notablemente no he encontrado ningún ejemplo, demo o sistema que la implemente.

En una empresa donde trabajaba tenía un compañero que era empleado, cliente y proveedor simultáneamente. Había comprado un vehículo que pagaba en cuotas, figuraba en la planilla de sueldos, era usuario de los sistemas y vendía artículos varios a la empresa.

Debes considerar que con las empresas también pasa algo similar: pueden ser clientes y/o proveedores o no tener relación comercial alguna, pero se registran sus datos porque por ejemplo quisieras tener información laboral de las personas que tienen el rol de clientes y/o provedores.

En algunos rubros, como inmobiliario y compra venta de vehículos, existe otra figura jurídica: el condominio. Por lo tanto tienes 3 tipos de clientes/proveedores: Persona, Empresa y Condominio.

Hay casos donde no vale la pena separar los clientes y/o proveedores en tablas diferentes. Actualmente estoy empezando la migración de un sistema de venta de lotes, que se inició con dBase II y terminó en FoxPro 2.5 y  estoy considerando la posibilidad de no tener la tabla de cliente/propietario.

La estructura que yo adopté es la siguiente:

Tabla: Ciente_Proveedor

IdClienteProveedor PK

Tipo: P=Persona, E=Empresa, C=Condominio

IdPersona FK relacionada con la tabla Persona puede ser nulo

IdEmpresa FK relacionada con la tabla Empresa puede ser nulo

IdCondominio FK relacionada  con la tabla Condominio puede ser nulo

Otros campos como: Límite de credito, etc...

Fíjate que el campo Tipo es redundante pero puede simplificar algunos procesos y consultas.

Tengo un formulario diferente para Persona, Empresa, Condominio y Cliente/Proveedor.

En el formulario de Cliente/Proveedor pides el Tipo (P,E) y de acuerdo a lo ingresado pides IdPersona o IdEmpresa en textboxs 

diferentes.

En el VALID de Tipo habilitas/deshabilitas, también puedes ocultar, los textbox de IdPersona e IdEmpresa

En el WHEN de IdPersona pones RETURN This.Parent.Tipo = "P" y en el de IdEmpresa RETURN This.Parent.Tipo = "E"

En el VALID de IdPersona traes los datos de la tabla Persona y pones en NULL IdEmpresa

En el VALID de IdEmpresa traes los datos de la tabla Empresa y pones en NULL IdPersona

Saludos.

Víctor.

--
 
 
 

[Alejandro Placereano]

Hola! yo uso una sola tabla para todo

y filtrado por tipo de entidad, en ese tipo de entidad, se define que es, por campos tipo bit, si es cliente, proveedor, etc, como son varios campos, puede seleccionar varios, es decir, que puede haber clientes que tambien son proveedores, etc

espero q te sirva

El miércoles, 10 de octubre de 2012 10:40:09 UTC-3, mpulla escribió:

[Miguel Antúnez]

Hola Mauricio, me parece acertado tu decisión, tiempo que vengo trabajando de esa forma. Y cumple con las definiciones de clases y herencias.

en este caso es la super clase persona el cual hereda a las demás clases en tu caso proveedor, cliente, empleado, usuario. etc.

Entonces debes tener la misma idea para hacer tus pantallas de mantenimiento, procedimientos, clases, etc.

como idea para tus pantallas te diría que hagas clases re-utilizables con los atributos de la clase persona, y los insertes dentro de tus formularios de proveedores y clientes.

Espero te sea de utilidad el comentario.

 

Saludos.

Miguel Antúnez Camones.

Lima - Perú

  

El miércoles, 10 de octubre de 2012 10:40:09 UTC-3, mpulla escribió:

Buen día.

En mi db tengo tablas Proveedor, cliente, empleado con campos repetidos como Nombre, apellidos, dirección, teléfono que siendo la misma persona la data es redundante.

Ahora quiero normalizar

Entonces tendría:
Tabla Persona con datos PersonaId, Nombres, apellidos, dirección, teléfono, etc
Tabla Clientes ClienteId, PersonaId, Forma de Pago, Vendedor, lista de precio, cupo de crédito, etc.
Tabla Proveedores ProveedorId, PersonaId, Forma de Pago, cupo de credito, etc.

Ahora viene la lógica para el ingreso de datos, aquí necesito de su experiencia si tienen algún modelo, pantalla, comentario de como lo hacen se los agradezco de antemano.

Esto es lo que tengo pensado al momento.

Cuando llega un cliente nuevo reviso que la data no exista en la tabla persona y si existe que no sea cliente, si cumple con las condiciones debidas entonces ingreso los datos a las tablas correspondientes.

Luego esta misma persona va a ser  proveedor ya existe en la tabla persona pero no es proveedor entonces ingreso datos a la tabla proveedor.

El mismo caso se aplicaría si la persona pasaria a ser empleado de la empresa.

Saludos.
Mauricio

--
 
 
 

--
Miguel Angel Antúnez Camones
mant...@gmail.com

[Arnaldo Toledano]

En épocas "pasadas", cuando el espacio en disco VALÍA MUCHO DINERO tenia una tabla donde guardaba
los datos de proveedores, clientes y transportes.
En un mismo registro tenia todos los datos, puesto que son prácticamente IGUALES.
Para saber si era PROVEEDOR, CLIENTE o TRANSPORTISTA, tenia un campo LÓGICO para cada una de las
actividades. Cuando este estaba en .T., significaba que desarrollaba esa actividad.
Después cuando el costo BITS-DISCO dejo de ser significativo, pase a utilizar una tabla para cada uno.

Tengan en cuenta que en aquella época los discos eran de 10,20 o 30 MEGAS, OJO MEGAS!!!!


Arnaldo Toledano

--
 
 
 

--
Arnaldo Toledano Tesys Informática Córdoba Argentina

[Norberto]

Hola Mauricio

Yo llevo una sola tabla para todas las categorias. En un campo identifico a que categoria pertenece.

Por ejemplo 2 cliente, 3 proveedor, 5 fletero, 7 empleado, 11,13 etc. o sea numeros primos

Cuando es cliente y proveedor sera 2*3=6, cliente y empleado sera 2*7=14, cliente, proveedor y fletero sera 2*3*5=30 etc.

Cuando quiero traer solo los proveedores busco las categorias donde MOD(categoria,3)==0

En esta tabla tengo un campo logico denominado Activo y cuando quiero eliminar el registro lo paso a .F. pero jamas lo 'delete' porque me destruiria la relacion con las demas tablas.

Dado que algunos pueden tener varias sucursales o depositos, llevo otra tabla donde hay por lo menos un registro por cada registro de la tabla anterior. Alli tengo los datos de domicilio y demas.

Utilizo un solo form para todas las categorias

[Hector R. De los Santos]

Bueno, para mi esa es la forma correcta de trabajar ese tipo de entidades.

Usando este modelo se tiene un mismo codigo unico para cada persona y solo es activar un tipo de ROL

A nivel de tablas no es muy complicado, con algunos Stored Procedures o triggers se resuelve. Y en formularios con clases

Yo casi en todos mis sistema lo manejo de esa manera. Tengo una tabla de PERSONAS donde guardo los datos genericos o datos de persona (nombre,apellido,telefono,etc), en esa misma tabla tengo el control para los roles (CLIENTE,PROVEEDOR,USUARIO,EMPLEADO,etc). Luego ya hay una tabla para cada ROL, por ejemplo TBL_CLIENTE donde guardo los datos especificios de Cliente (Condicion de pago, limite de credito, % descuento, etc.)

En VFP tengo una clase que se encarga de manejar este tipo de mantenimientos, es solo agregar la clase y poner algunos parametros.

Adjunto algunas imagenes de algo que tengo cerca,  el formulario de Proveedores

Suerte!

:: HDS Consultores TI
Servidores | Redes | Programacion | GNU/Linux | PostgreSQL
Web: http://hdsconsultores.net
Blog: http://codigohds.com
Linux User #:320363

--
 
 
 

[mapner]

Yo lo trato así,

Tengo una tabla Personas (con una clave primaria PER_ID) que tiene campos comunes como nombre dirección, datos de contacto, etc...

Luego tengo tablas de Clientes, Proveedores, etc y tienen un campo referencia o clave foránea PER_ID (relación 1:1) que apunta a la tabla Personas.

La parte visual la trato con una clase ya definida para tomar los campos de Persona en una solapa principal y en las subsiguientes solapas se especializan al tipo de TERCERO que se trate (Cliente, Proveedor, etc.)

Este tema es un clásico y es el manejo de las entidades de TERCEROS y se hace por medio de una relación de composición que es cuando en la definición de una clase se incluye a otra clase para complementar su estructura, de esta manera se evita hacer HERENCIA.

 Ej.

Persona

PER_ID (PK)

PER_NOMBRE

PER_DIRECCION

PER_ESTADO

PER_PAIS

PER_TELEFONO

PER_EMAIL

...

Clientes

CLI_ID (PK)

PER_ID (FK -> PERSONAS)

CLI_CREDITO

CLI_FECHA_ULTIMA_VENTA

...

Proveedores

PRV_ID (PK)

PER_ID (FK -> PERSONAS)

PRV_DEUDA

PRV_FECHA_ULTIMA_COMPRA

...

Si quisiera consultar Proveedores

select per.*,prv.* from Proveedores prv join Personas per on prv.per_id = per.per_id

Es más un Cliente y un Proveedor pueden ser la misma persona en diferentes roles...

Otra cuestión interesante es que una Persona puede relacionarse M:N (muchos a muchos) con otras personas por medio de una tabla de relación y así mantener una BD de contactos.

Personas_Contactos

PER_ID

PER_ID_REF  

De hecho las redes sociales como FB hacen esto...

saludos

El miércoles, 10 de octubre de 2012 10:40:09 UTC-3, mpulla escribió:

[Carlos Miguel FARIAS]

Tambien defino una tabla persona con datos genéricos (con su propio id, si es necesario autoincremental) y tablas para las distintas subcategorias funcionales (proveedor, cliente, usuario, etc.), la clave primaria de las subcategorias es la primaria de personas (relación 1 a 1).
Esto práctico porque no obliga a tener datos externos (por ejemplo documento) para manejar las personas (aunque en general todos tienen CUIT/CUIL en Argentina).
De esa manera podes manejar a "Doña Rosa" sin tener que preguntarle el documento.
Además, en tabla aparte, manejo, relacionado con personas, todos los posibles tipos de documentos que una persona podría llegar a tener.
También sistematizo por separado las direcciones (codigo postal, calle, numero, ciudad, etc.) donde los direcciones (lugares) están en una entidad aparte, pero sirve porque simplifico por ejemplo manejo de telefonos fijos. Tengo sistemas donde necesito manejar mas de una dirección por persona (Legal, Postal, Laboral, etc.) que pueden ser iguales o diferentes.
En fin, la conveniencia de normalizar van a estar supeditadas a las necesidades del sistema de información subyacente.
Saludos: Miguel, La Pampa (RA)

--
 
 
 

[mpulla]

Hola Foxeros.

Muy agradecido con todos por sus aportes

Después de haber leído sus recomendaciones tengo la idea más clara de normalizar Persona = cliente, proveedor, empleado, etc.

Nuevamente gracias.

Mauricio

[Juan Salvador]

Aquí les publico un ejemplo de Jerarquías y Retículas:

- En las jerarquías de especialización:
   - Cada subtipo hereda atributos y relaciones...
      - de su (único) supertipo directo
      - y de sus supertipos predecesores, hasta la raíz

   - TITULAR hereda de DOCENTE, EMPLEADO y PERSONA

- En las retículas de especialización:
   - Un subtipo hereda atributos y relaciones...
      - de sus supertipos (múltiples) directos => herencia múltiple
      - y de todos sus supertipos predecesores, hasta la raíz

   - BECARIO hereda directamente de EMPLEADO y ESTUDIANTE, e indirectamente hereda de PERSONA.

* Los subtipos compartidos dan lugar a retículas

- En herencia múltiple pueden surgir conflictos al heredar atributos distintos denominados igual:
   - BECARIO hereda “jornada” de dos predecesores ¡¡ !!

- ¿Cómo resolver esta situación?
   - Renombrar algunos de los atributos en conflicto
      - BECARIO hereda ambos atributos:
         - “jornada” corresponde a “jornada” de EMPLEADO y
         - “jornadaEstudio” corresponde a “jornada” de ESTUDIANTE
   - Definir un orden de prioridad en la herencia
      - BECARIO hereda “jornada” de ESTUDIANTE y no de EMPLEADO

Aquí unos enlaces a paginas muy útiles sobre Base de Datos, donde encontraran definiciones y ejemplos muy didácticos:

- Base de datos 11'

- Base de Datos - TA4

- Base De Datos I

Saludos.

[mpulla]

Hola Juan.

Gracias por los articulos esta muy buenos.

Saludos.
Mauricio

[Miguel Ab]

Os cuento como resolvía estos casos en SQL Server, por si es de aplicación (algo que era muy sencillo). Adelanto que soy aprendiz de VFP y seguro que se me escapa algo.

Yo agrupaba los campos comunes en una tabla (por centralizar la información y ahorar espacio). Esta tabla tenía un campo clave que luego se usaba como clave foránea en cada tabla dependiente que contenía datos diferenciados como clave foránea.

El caso era más complejo, pues los datos diferenciados tenían diferentes privilegios de acceso (eran datos sensibles) lo cual solucionamos limitando el acceso a través de diferentes vistas. El problema que se podía presentar con el borrado, se solucionó programando un trigger que mantenía los datos hasta que existiran datos en las tablas dependientes y en el último borrado se limpiaba la tabla común. El problema de actualización de datos era sencillo pues solo se podía hacer desde un par de "tablas dependientes"/formularios que eran gestionados por la misma persona.

Saludos.

[Jesus Rojas]

Estimados, Yo tambien guardo en una sola tabla los clientes, proveedores, trabajadores, etc. Para los cuales empleo un solo ID, pero mi consulta va en que nombre standard le puedo considerar a nivel de diseño de la base de datos?. Actualmente le estoy considerando como ENTIDADES, pero comenten que optros nombre emplean para clientes, proveedores, trabajadores, etc. Necesito un nombre común para tabla, ya que en diseño de los formularios, cada uno va a tener su propia pantalla, clientes, proveedores, etc. diferenciándolo con una clave foránea TipoEntidad

Saludos

Manuel 

[David Salazar]

Nombre PERSONA

2014/1/17 Jesus Rojas <jesusr...@gmail.com>