Hola,
Estoy revisando la app vGestion, me parece una estupenda app para aprender, lo que no acabo de entender muy bien es el tema Entidades y Entidades de Gestión, que sentido tiene no tener el clasico clientes, proveedores, Vendores...
Supongo que es por temas de abstracción, pero no lo consigo entender muy bien...
Alguien, por favor, me lo puede explicar un poco...
Gracias de antemano
Hola.
En Velneo no puedes presentar registros de varias tablas en una sola rejilla.
Si quieres hacer, por ejemplo, una agenda de teléfonos global (clientes, proveedores, contactos, etc.), necesitarás que todos estén en la misma tabla. Ese es el origen de tener una única tabla Entidades. Complica un poco la gestión, pero te garantiza que todos los "entes" con los que te relacionas están en la misma tabla.
Todo lo demás son herramientas para poder relacionar entidades entre ellas (los contactos de un cliente, las delegaciones de una empresa, una misma entidad como cliente y proveedor, etc.).
Es un poco más complejo, pero con esto puedes hacerte una idea global.
Saludos,
Fran Varona
Aqui tienes uno de los primeros articulos que escribi en el blog, y donde hablaba precisamente de este tema:
un saludo
Jose Luis
Ok, Aclarado,
Fran, José Luis, Muchas gracias!!!
Pues a mi modo de ver, la abstracción es pura teoría de base de datos con muy poca utilidad en la practica. Resulta que para no duplicar 3 o 4 clientes que a su vez son proveedores, hago una mega tabla y engordo a base de bien en cada registro por los campos no comunes que no relleno. Encima, complico la programación en cada paso para conseguir mejorar solo en ese caso en el que quiero referiría a las entidades como un todo (por ejemplo en un mailing). Creo que es mejor simplificar todo y, en el caso de que necesite unificar, utilizo una tabla en memoria. Y para concluir, nos olvidamos del principal problema de tener todo en una tabla. Resulta que tendrá muchos mas registros y esto significa que cada búsqueda tardará mas, sobre todo en la nube. Otro problema añadido se dará en l caso de que queramos hacer un alta masiva. El tiempo de cada alta va en función del numero de registros que tengamos en esa tabla, ya que Velneo efectúa una comprobación previa para evitar duplicidad de claves única.
>Pues a mi modo de ver, la abstracción es pura teoría de base de datos con muy poca utilidad en la practica.
Desde la experiencia, te digo que esa 'pura teoria' es IMPORTANTISIMA en la practica.....saltarte los principios de diseño de bases de datos por 'simplificar' te pasa factura mas temprano que tarde....especialmente si tu sistema es minimamente complejo....
Yo cuando me iniciaba como desarrollador profesional en 1997 ( desde crio hacia software, solo que por hobby, asi que solo cuento desde cuando me ganaba la vida con el soft)...tuve una argumentacion similar con un socio de 'mucho mas experiencia practica', y al final la mitad que le correspondia diseñar tuvo muchas de estas 'simplificaciones' y yo, recien salido de la universidad, me puse firme en ser estricto en los principios del buen diseño.....
Viendo esa aplciacion al dia de hoy, el tiempo me ha dado la razon, la parte 'simplificada' esta ahora llena de parches (vendria a ser mas o menos vConta en cuanto a alcance equivalente), y ha provocado muchos dolores de cabeza, perdidas economicas y de horas-hombre....La parte diseñada respetando a rajatabla los principios de diseño, es claramente mas robusta, y mucho mas facil fue siempre de hacerles cambios o agregarle funcionalidad....
Por favor, no caigan en esas tentaciones...en este caso, se debe encarar con un modelo pensado en ACTORES (las Entidades como llaman uds, y casualidad, asi se llamaba nuestra tabla en nuestro ERP)....alli se guardan todos quienes interactuan con la organziacion y los ROLES (proveedor, cliente, empleado, vendedor externo, etc...)
Evitar la redundancia de datos, seguir estrictamente principios de optima normalizacion....es imprescindible....Todo 'gasto' adicional en tiempo y esfuerzo se recupera con creces a futuro en una aplicacion bien diseñada.
Totalmente de acuerdo con joanloal, hasta llegué a pensar que Vgestión se publicaba como apoyo exclusivo al estudio y haciendo complejo vbase para evitar desarrollos a partir de esta open apps.
Razoneis como razoneis no tiene sentido ese diseño, una pena porque Vgestión está muy bien como punto de partida para otros desarrollos con la inmensa cantidad de tiempo y trabajo que ahorra pero para mí el lastre del diseño de ENTIDADES me hace dudar, yo llevo muchos años con la v6 con aplicaciones muy gordas y en alguna de ellas aún tengo que modificar estructura en Clientes , Proveedores etc. para dar vida a otros procesos y otros planteamientos y eso que con V6 Y V7 se hace en un santiamen y sin errores porque las cosas están muy claras con el diseño que estamos hablando de ENTIDADES puede dar lugar a confusiones y meteduras de pata si llevamos algún tiempo sin trabajar con ella.
Abstracción SI pero claridad y simplicidad primero
@cjribera: Totalmente de acuerdo contigo, y mi experiencia data ya de la decada de los 80 :(
@benito: Yo también llevo años con v6, con aplicaciones muy gordas, y el mayor lastre de la vBase-v6 es la tabla de entidades:
- Cada vez que en gestión necesitabas una campo para clientes -> modificar tabla entidades
- Campo para proveedores -> Modificar tabla entidades
- Querías que la aplicación fuese, por ejemplo para alumnos, profesores -> vBase NUEVA.
Luego, la contabilidad (vConta-v6) era un mapa diferente -> Cada cambio de vBase implicaba un cambio de tablas también en vConta. Si no lo hacías -> errores en las tablas por estructura diferente.
Muchas veces pensaba en separar los datos de gestión de los puramente datos de la entidad. Por lo que mi mayor obsesión era que en v7 eso estuviese claramente separado. La vBase debe ser en esencia lo mismo que los contactos de tu teléfono, pero con la posibilidad de definir los roles, que los hemos llamado tipos de entidad, según quieras interactuar con ellos desde tu aplicación. Y los datos específicos de tu aplicación deben estar en esta. Es decir las condiciones de gestión con un cliente deben estar definidas en el módulo de gestión.
Esto además se hace mucho mas importante en la v7, para poder aprovechas la modulación que permite la herencia.
La simplicidad muchas veces nos lleva a errores, el buen análisis es lo importante.
Nacho
Mi compañero Nacho lo explica perfectamente.
Yo añadiría una cosa más, si quiero una gestión y además un CRM, cuando voy a buscar los datos para enviar un mail, a donde voy? a clientes? a proveedores? hago una tabla juntandolos?
No son solo "3 o 4 clientes que a su vez son proveedores" es un sistema de trabajo que además no es nada nuevo cualquiera que haya visto vBase 6.X lo conoce perfectamente.
Incluso se ha mejorado respecto a 6.X en cuanto a la integración de vBase con vConta, pero eso ya es otra historia.
www.vTODO.net
Para Nacho y comercial.guida21, ante vuestro claro razonamiento lo asumo y envaino mi comentario.
Muchas gracias
Una cosa mas, alcaro que no conozco a fondo las open apps de V7, por eso la consulta.....
Donde dice "pero con la posibilidad de definir los roles, que los hemos llamado tipos de entidad"...
ME asalta una duda....usan un campo estilo TipoEntidad_ID en la tabla Entidad?
Si fuera asi, como salvarian el caso de un cliente que es a la vez proveedor? que valor tendriaTipoEntidad_ID ?
.
Quiza entendi mal...al menos en mi caso, lo que hago son tablas separadas para cada rol...
De esta forma, una entidad con multiples roles, simplemente tendra registros en las multiples tablas de rol....Si es una entidad que es cliente y proveedor a la vez, el mismo Entidad_ID estara en la tabla de proveedores y en la de clientes,....
Estas tablas de rol tendran sus propios atributos, (aparte de los atributos generales que estarian solo en la tabla Entidad).....
.
Es decir, se puede construir un formulario general para Entidad....con campos ocultos de las tablas de rol, tal que si se llama al formulario desde el modulo de Ventas, pidiendo modificacion de datos de un cliente, se abriria el formulario estandar, y se harian visibles los campos de la tabla Cliente (LimiteDeCredito, SaldoVigente, SaldoVencido, etc.)...
Idem si se esta en el modulo de recursos humanos...se habilita el formulario de entidad, y se harian visibles los campos relativos al modulo y al rol de 'empleado' (SalarioBasico, Horarios, FechaDeIngresoAlTrabajo, etc..)....
.
Al aceptar el formulario en cualquier modulo, se actualizan los datos de la entidad y los datos del rol (o se dan de alta nuevos registros, en caso necesario)......el usuario no se dara cuenta que esta modificando varias tablas porque sera un solo formulario....pero se actualizaran campos de la tabla Entidad, o de la tabla clientes, y sus tablas relacionadas donde haga falta, obviamente asegurandose que la transaccion sea ACID compliant....
.
Espero se entienda mi politica, es que quisiera saber si en las open apps de V7 se hace asi...
Gracias de antemano por la info, salu2.
@cjribera:
No te preocupes, que está resuelto totalmente independiente:
- Una entidad podrá ser de 100 tipos diferentes, sin tener que tocar para nada la tabla ENT
- Puedes buscar en entidades, por un tipo concreto (por ejemplo entidades "cliente"), mediante un localizador que hemos desarrollado, al estilo v6.
- Existen funciones para ser usadas desde las aplicaciones. Por ejemplo, para crear una entidad, pasándole el tipo que quieres que sea, y se asegura que quede defina como tal.
- Cada aplicación podrá definir sus propios tipos (roles), y el usuario podrá asignarlos a cada entidad, de una forma muy sencilla.
- La vBase se podrá usar para gestión (clientes, proveedores, transportistas,..), para videoclubs (actores, directores), academias (profesores, alumnos), etc.... Sin modificar nada en ella, y conviviendo los tres tipos de aplicaciones y los que quieras.
Yo la uso desde un ERP, un CRM, un gestor documental, un gestor de correo, la contabilidad...
Tengo escritos dos artículos, que se publicarán en el blog de Velneo en los próximos días, que espero ayuden.
Puedes leer este (de mi blog), que hace referencia a la vBase v1.0. http://nachov7.wordpress.com/2010/07/07/vbase-entidades-y-categorias/ , en él se habla de categorías (así lo habíamos llamado en esa versión), pero en la versión actual pasó a llamarse "Tipos de entidad" pues la experiencia con los usuario es que se entiende mejor con este nombre.
un saludo
Nacho
Hola,
Os pongo lo que hace tiempo puse en facebook, y me gustan que los demás decidan ir por este camino.
Sustitución de los campos TIPOS DE ENTIDADES booleanos, por una tabla de propiedades de entidades
<div class="clearfix">
<div class="mbs mbs uiHeaderSubTitle lfloat fsm fwn fcg">de Antonio Vela, el jueves, 03 de septiembre de 2009 a las 16:53</div>
</div>
(Cambiando la documentación sobre mi vBaseVisual particular)
Por todos es conocido la funcionalidad que tienen los campos booleanos
asignados en vBase como tipos de entidades. Pues bién, he decidido
cambiar este tipo de funcionalidad en mi vBaseVisual particular.
Los Tipos de Entidades que estoy analizando para un proyecto son:
- Usuario
- Comercial
- Transportista
- Organismo
- Ciudadano
- Precliente
- Acreedor
- Cliente
- Contacto
- Empleado
- Asociación
- Proveedor
La existencia de estas entidades, es debido a que cada una de ellas llevarán asociadas distintos módulos operaciones dentro de la aplicación, así como distintos tipos de formularios y subformularios entre otras operaciones que se velnearán.
Repasando los vídeos sobre herencia inversa y/o puntos de insercción que se podrán poner en los separadores de formularios; he optado por quitar los campos de tipos de entidades declarados en la tabla entidades y llevarlas a otra tabla que denominaré -propiedades de entidades-.
En esta tabla de propiedades crearé los tipos de entidades con una estructura básica como la siguiente:
- Código
- Descripción Tipo Entidad
- Aplicar Si o No
- Valor
El Código será autonumérico, ya que serán los enlaces plurales de la tabla maestra entidades. Por lo tanto ya no tendremos límites a la hora de crear tipos de entidades. Hasta ahora sólamente había que crearlas y velnearlas allí donde hiciese falta condicionándose su uso.
La Descripción del Tipo de Entidad podrá ser cualquiera de las necesarias que hayamos creado como información a incorporar en los puntos de inserción de los separadores de formularios.
Aplicar Si o No, será un campo booleano que nos servirá para condicionar el/los formulario/s correspondientes a cada entidad para poder interactuar con ellos donde haga falta.
Valor, será un número único que asignaremos para identificar así los registros que podrán usar los puntos de insercción.
De esta forma (y cuando tengamos operativa la herencia inversa, que sea pronto) ya no tendremos problemas ninguno a la hora de incorporar nuevos tipos de entidades a las fichas correspondientes.
También (para eso lo he pensado) podemos añadir multiples tipos de entidades a cada ficha.
La otra parte, es la del diseño correspondiente de las tablas,formularios y subformularios que se podrán incorporar dentro del formulario de las fichas. Tipo módulos de aplicación.
Se diseñan por independiente y gracias a los puntos de inserción los incorporamos en el formulario principal (o en cualquiera secundario). Es aquí donde usamos el campo -Valor- incorporado en cada tipo de entidad,
con condición de activo/visible según el campo -Aplicar Si o No- de la ficha en curso.
Ejemplo:
Creamos -Ciudadanos-, con sus formularios y subformularios correspondientes a las tablas.
Creamos -Curriculum-, con sus formularios y subformularios correspondientes a las tablas.
Creamos -Multas-, con sus formularios y subformularios correspondientes a las tablas.
Creamos -Actividades-, con sus formularios y subformularios correspondientes a las tablas.
Creamos -Impuestos-, con sus formularios y subformularios correspondientes a las tablas.
...etc....
A cada uno de ellos le asignamos internamente un -Valor- en variables locales a los formularios/subformularios de cada tipo de tabla.
Cuando editemos cualquier ficha, cargaremos previamente las propiedades (puede ser en un array), serán activos/visibles aquellos formularios/subformularios que coincidan con el -Valor- de la ficha en curso.
¿Qué aparecen nuevos tipos de entidades?
Se diseñan los formularios(subformularios Se les dá un valor único para identificarlos
Se incorporan manualmente o por proceso en las fichas correspondientes.
Y a funcionar....
Creo que debe funcionar así perfectamente, esperemos esta funcionalidad mientras tanto.
- Módulos Heredables = Puntos de inserción = Herencia Inversa -
saludos
Antonio Vela
http://www.velavisual.com
Hola Nacho, gracias por la info....
Solo quiero aclarar que me parece que mi diseño es mas parecido a lo que dice velavisual...
Si uso los campos booleanos como referencia para filtros y busquedas....pero en realidad uso tablas separadas para roles, por ejemplo, velavisual propone 1 tabla me parece, yo uso muchas, una tabla por cada rol....
Mas que todo porque cada rol podria necesitar atributos diferentes....
Por ejemplo, los atributos del rol 'Empleado' : SalarioBasico, FechaIngreso, y sus horarios, no tendrian razon de estar vinculados a la tabla 'Entidad'...ni tampoco me parecería ponerlo en una única tabla de roles, pues como digo, cada rol requeriria atributos distintos, en cantidad de atributos y formato de cada uno de estos....
No se que piensan ustedes, o como han resuelto el tema, si es de verdad como he entendido, pon er esos atributos en la misma tabla de entidades, o si usan otras tablas....
Espero se mantenga este intercambio, para que salgan ideas interesantes para todos.
Salu2.
La verdad , es dificil llegar a una conclusion final, en un tema como este, porque cada caso es muy particular, y depende mucho de las necesidades de cada cliente.
Me explico, tengo clientes con talleres de automoción, que utilizan las primeras aplicaciones que diseñé hace años, donde las tablas de Clientes y Proveedores estan separadas, y hoy dia, seria dificil convencerles de lo contrario, ya que raramente un proveedor, llega a ser cliente, y la complejidad de mezclar las 2 tablas y tenerlo todo compartido no compensa con el beneficio de trabajo que ahorra al usuario y el trabajo de desarrollo que genera.
Pero tambien tengo clientes que se dedican al almacenaje de productos agricolas y fitosanitarios, donde se da justo el caso contrario, el 90% de los registros de clientes y proveedores son comunes, es decir, el agricultor es proveedor de cereales, etc, y cliente de semillas y abonos y donde la excepcion es que una entidad sea SOLO cliente o solo PROVEEDOR. Aqui no tendria sentido tener 2 tablas separadas.
Por eso, es cada uno en su caso particular, el que debe valorar si merece la pena, abstraer el esquema, o es mejor mantener las tablas de forma independiente.
un saludo.
Jose Luis.
@cjribera:
Vamos a desglosar el problema en partes, empezando por el final:
- Datos particulares de cada ROL o TIPO DE ENTIDAD: Efectivamente dependiendo de como nos relacionemos con la entidad, necesitaremos unos datos específicos. Así si es de tipo cliente, necesitaremos saber, por ejemplo, la tarifa que le aplicaremos, la forma de pago.... Si es un empleado, los datos serán totalmente diferentes. Y así con cada caso. Por lo tanto es indiscutible que necesitamos muchos datos diferentes, dependiendo del tipo. Por lo que debemos concluir que tendremos una tabla distinta por cada entidad - tipo de entidad. Y estos datos no podrán estar en una solución básica, deberán estarlo en la aplicación que los use (en unos casos una gestión, en otros una nómina,....). Esto nos lleva a la conclusión que en vBase no puede haber ninguno de estos datos.
- Entidades: Las entidades tienen unos datos que son inhentes a ellas y esos serán los que deban estar en esta tabla u otras relacionadas (nombre, dirección, teléfono, e-mail.....).
- Establecer los TIPOS de cada ENTIDAD: Dentro de vBase tenemos una tabla TIPOS DE ENTIDAD, donde cada aplicación puede crear los TIPOS que va a usar (existen una función para ello). Y como el usuario tiene que poder decidir con cada ENTIDAD, de que tipo/s es, hemos creado una tabla histórica de ambas ENTIDAD -TIPOS DE ENTIDAD (Llamada internamente ENT_ENT_TIP). De esta forma desde vBase podremos cuales de nuestras entidades son clientes, empleados, etc...
- Conectando tabla específica de cada tipo de entidad, con la entidad: En vBase tenemos las entidades, y podemos decidir de que tipo son. En cada una de nuestras aplicaciones tendremos las tablas específicas que necesitemos para cada tipo. Ahora lo que nos queda es conectarlas. Para esto lo que yo recomiendo es hacer nuestra tabla, histórica de la tabla ENT_ENT_TIP.
Dentro de vBase tenemos las funciones necesarias, para hacerlo todo de una forma limpia. No me voy a extender en explicaciones técnicas, pero puedes localizar entidades que sean solo clientes o empleados (sin booleanos, ni límites de tipos), puedes poner una control de edición en un formulario, donde escribas el nombre de la entidad, y se localice solo entre las que son clientes, etc.... Está todo pensado, y si creéis que algo no lo está lo exponéis.
El mejor ejemplo para ver su potencial está en la vConta.
un saludo
Nacho
Refloto el tema porque estoy revisando Velneo de nuevo, despues de un tiempo...
Viendo la vBase, me asalta una duda....porque existen campos para Telefono1, Telefono2, Telefono3 (ver imagen)?
Que pasa si una entidad nececita mas telefonos?
No seria mejor tener una tabla de telefonos propia? Segun mi experiencia, lo ideal seria una relacion muchos a muchos, donde una entidad pueda tener muchos telefonos, y a su vez un mismo telefono pueda ser compartido por muchas entidades (numeros piloto en empresas grandes con centrales telefonicas y extensiones, usados como alternativo al movil del empleado que es contacto de negocios de nuestro cliente final)...
Lo digo porque en mi ciudad hubo un digito extra, acompanado de cambios de numeracion.....al cambiar el numero piloto, ya se cambiaba en todas las estidades la informacion, pues solo habian las tablas de muchos a muchos que decian EntidadID, TelefonoID, Extension, Referencia.
Al estar referido por TelefonoID, pueden haber muchos cambios de numeracion y se evitaria tener que cambiar el numero en muchas entidades, con el trabajo mayor y riesgo de inconsistencia de datos.
Obviamente esto se enmascara al usuario final, poniendole una interfaz plana, pero manejandose internamente con los ID y las relaciones muchos a muchos.
Idem los email, yo los puse en una tabla, para los casos de email compartidos por varias entidades (ventas@empresa.com compartido como email alternativo por muchos vendedores), o entidades que tengan mas de 3 emails (info@empresa.com, ventas, soporte, despachos@empresa.com, etc...).
Que opinan?
[attachment=14249,1222]
cjribera@
Esos campos que hay en Entidades en vBase, son restos de la versión 1.0, que se han dejado para que si alguien tenía datos en esa versión se pudiesen recuperar con unos procesos que existen en el proyecto de datos. Pero en realidad ya no se usan, en esta versión 2.0, esos campos están en una tabla (CTT) con una relación con Entidades 1 -> n, no teniendo ningún límite de teléfono ni e-mail por entidad.
Igualmente con las direcciones, también existe una tabla DIR que está relacionada n <- 1 con Entidades, y con contactos CTT.
Por otra parte la tabla de Contactos (CTT), se puede relacionar con cualquier otra tabla mediante un campo indexado que se llama ID_REF.
PD: En la siguiente versión 2.1 esos campos ya desaparecerán.
un saludo
Nacho
http://www.vtodo.net