Desde mi punto de vista la gran diferencia entre analizar en Velneo y en otras plataformas, reside en que en Velneo las particularidades de su base de datos, nos van a permitir pensar en el Qué y no en el Cómo.
Esto es fácil si asociamos
Parte Izquierda = Qué,
Parte Derecha = Cómo presentar la información
En otros tipos de lenguaje y bases de datos relacionales para obtener el contenido de campos deberemos recurrir a procesos, es decir al “cómo proceso una información para llegar a un resultado”.
Si pensamos en el cómo , pensaremos en leer una información, tratarla y obtener un resultado, es decir en un proceso, y en Velneo esto normalmente no va a ser así.
La mayor desventaja de resolver la lógica deseada en un proceso, es que muchos de los calculos y resultados intermedios que nos serán utiles en el futuro quedarán aislados , escondidos y no accesibles, relativamente bien resueltos si hemos utilizado funciones pero que en muchos casos olvidaremos o no se ajustarán a la nueva necesidad por la urgencia con que fueron hechas.
Creo que es mucho mas conveniente que todo cálculo, acumulado o valor que en cualquier momento necesitemos, este accesible desde cualquier punto de la base de datos, desde cualquier formulario, informe, rejilla o página web.
Para ello lo primero será definir las tablas con los datos que van a ser introducidos y los campos que queremos obtener como resultado.Hasta aquí ninguna diferencia.
A partir de este punto debemos tener en cuenta que en Velneo:
- Crearemos todos los campos en las tablas que sean necesarios.Será mucho más cómodo crear un campo que utilizar una variable en un proceso. Ya que la variable estará desconectada de la base de datos y el campo ,sin embargo disponible en todo momento.
- Crearemos todos los índices que sean necesarios para establecer cualquier ordenación que nos interese.
- Crearemos todas las relaciones que necesitemos entre dos tablas, podrá haber tantos enlaces históricos entre dos tablas (Por distintos índices) como nos convenga.
o Por ejemplo entre Clientes y Facturas podremos tener tantos enlaces a histórico como nos convenga con sus diferenets índices (Factura-Fecha) (Factura Importe) (Provincia Factura Importe) (Etc) , lo cual nos dará por una parte ordenación y posibilidades de los punteros singular del plural por posición o por índice.
Y nada de esto penalizará los rendimientos de la aplicación.
A continuación deberemos resolver todos los campos de salida que hemos definido y crear todos los campos intermedios y tablas que sean necesario para ello, pero siempre pensando en el qué, nunca en el cómo , nunca mediante procesos.
Un ejemplo sencillo.
En clientes tenemos el campo Total de Ventas .
Si pensamos en el cómo , la respuesta será leer todas las ventas de un cliente, utilizar ua variable donde acumulemos y estaremos ya estamos elaborando un proceso. No es lo correcto en Velneo.
Si pensamos en el qué , el total de ventas de un cliente es la suma del importe de todas sus facturas. Por tanto necesitaremos darle un valor a ese campo.
El Campo total ventas es la suma de sus facturas, es decir una Formula Histórico o el resultado de una actualización provocada por los registros de cabecera factura donde está el total de cada una de ellas.
Para ello solo necesitaremos que en la base de datos existan los enlaces necesarios y establecer su definición o actualización.
Si lo complicamos un poco más, a lo mejor queremos obtener el promedio de importe vendido por factura.
En ese caso es : El importe dividido por las unidades vendidas. Necesitaremos un campo nuevo, que será el número de ventas realizadas , una nueva formula histórica o una actualización según nos convenga.
Y el valor del campo resultado será la división de ambos.
Esto parece obvio, pero a medida vayamos complicandolo, las diferencias entre ambas formas de pensar serán más patentes.
Si queremos obtener una estadística de ventas por meses y artículos, deberemos olvidarnos de procesar información . Crearemos en la base de datos la tabla tal y como la queremos obtener, definiremos un índice único por artículo, mes y año, un enlace indirecto desde la línea de Ventas , e indicaremos que esos registros se créen automáticamente desde la actualización correspondiente.
Pero nunca pensaremos en el cómo, es decir “Leeremos todas las ventas de un cliente e iremos acumulando….”
Siguiendo esa forma de programar, entenderemos por qué en Velneo, no es lógico hacer un recalculo para obtener un saldo de existencias o un saldo de una cuenta de contabilidad en cualquier fecha , sino que todos esos valores y resultados deberám estar definidos y resueltos en la base de datos, sea cual sea la fecha o incluso la hora si la aplicación lo requiriera.
Si funcionamos de esa manera, cauntos mas cálculos realicemos, cuanto más aparentemente se complique todo, más sencillo será resolver cualquier petición del cliente porque más datos y valores tendremos accesibles desde cualquier punto de nuestra aplicación.
Si embargo cuantas más cosas incluyamos en procesos, más dificil sera acceder a ellas, más dificil será recordar la función que lo resolvía y más dificil modificar el programa.
Al novel , le puede parecer que la base de datos de Velneo no da para tanto, a mi me costó casi 5 años, pues no he hecho procesos que despues he encontrado absurdos, pero recuerdo grátamente mi último gran programa en Velneo, un control de costes de producción para una empresa con más de 200 trabajadores en planta y todo tipo de maquinaria.
Procesos largos = 0.
Todavía hoy alucino cuando me piden un nuevo requerimiento o resultado, un nuevo coeficiente o cambiar un concepto para afinar la rentabilidad de cada proceso y pieza lo cual se dá cada 5 o 6 meses..
Yo me limito a preguntar, eso que me pides ¿Que es? .
Apenas recuerdo nada de la aplicación , pero tan solo tengo que ir a las tablas, buscar los elementos que necesito y definir el nuevo resultado, que probablemente volveré a utilizar dentro de muchos años.
Eso es lo mejor de Velneo, que la base de datos , relaciones, etc no están para el disfrute de la ejecución y el usuario, sino para el propio programador.
Si os interesa podeis leer mas en “Mas alla de la bases de datos relacionales”
