No tengo claro para qué sirven los hermanos contiguos.
¿Para que un registro apunte al anterior o el siguiente?
Nunca necesité hacer algo así excepto cuando programaba en QBasic5 tablas sin indexar y me inventé los índices.
Yo creía que el hermano anterior era el que tenía una clave anterior: numérica, alfabética o de fecha-hora, según un índice definido.
¿Que quería leer el anterior? ReadPrevious. ¿Siguiente? ReadNext.
Ya. Que aquí no hay eso. Ni tener un registro con clave A, otro con clave D y leer “B” para poner el puntero en medio o donde sea y pasar después al siguiente o anterior. O me parece que esto si es posible en Velneo, pero da igual, no voy a eso.
Por periodo de pruebas tengo en vERP 11.451 apuntes contables en la tabla APU_C relativos a 3162 asientos en la tabla ASI_C.
Borrar en 3P solo los apuntes desde un “Recorrer lista eliminando fichas” genera una transacción con 3.483.989 operaciones que tarda solo 43 minutos.
¿?
Solo hay asientos → apuntes, no más plurales con datos en otras tablas.
Ya me dieron en soporte algunas explicaciones y opciones pero …
¿Qué opinan ustedes de esto?
Bonus Info:
A medida que se eliminan fichas, el proceso elimina un mayor número de registros por segundo. Representado en gráfico supongo que resultaría exponencial.
Desde 8 registros en 5 segundos a más de 300 en 1 segundo así a ojo, por encima (en 3P).
Bonus Info2:
He quitado los dos campos a hermano contiguo de la tabla APU_C y la transacción devuelve en un minuto 12 segundos este resultado:
Eso es la teoría, pero como hemos visto en muchas características de la Base de datos Real de Velneo, ponerlas en práctica y en arquitecturas cloud es otra cuestión.
Que ¿ qué me parece que la misma transacción pase de tardar 43 minutos a 1 minuto 12 segundos simplemente por eliminar 2 enlaces “virtuales” de la tabla, ya que las operaciones se reducen en un 98% ?
A mí, me parece muy mal, pero habría que consultar al diseñador o arquitecto de la Base de datos para que nos iluminara.
Exacto. Eso mismo pensaba yo.
La casualidad de estar importando datos a la aplicación. Y son tan solo 11.500 apuntes generados en 3 meses por una PYME.
Si el proceso de importación (también sin plurales) de 11.451 apuntes en 3P tarda 3 minutos 21 segundos, enganchando cada apunte a registro de asiento, a la cuenta de mayor y su auxiliar y buscando los NIF en la tabla ENT_M de entidades …
… no se comprende que el borrado en 3P, mucho más sencillo, tarde muchísimo más tiempo.
No me hago idea de si 3min 21s es mucho o poco para importar 11.451 apuntes contables en 3P, la verdad, pero puedo aceptarlo.
Bonus Info: Eliminación del primer apunte, mediante “seleccionar ficha por pos(1) / elim.ficha sel”
Eliminación de un segundo apunte !! OMG !! esto es iluminación !! No me lo esperaba !!
¿Y qué pasará en el tercero ? Tampoco me esperaba esto … ¿¿??
Cuarto, quinto y sexto seguidos pero de uno en uno:
Y diez registros borrados en un “Recorrer lista eliminando fichas”:
Creo que eso escapa mi numerología 8127 op / 10 registros= 812ops por registro eliminado, peor que borrando de uno en uno …
¿Y cien?
Pero si vacío la tabla de apuntes, importo solo 300 y luego los borro …
Son 939 operaciones al importar y 6153 al borrarlos, que no es lo mismo cuando hay 11000 apuntes más.
Si quieres puede probar a dejar los punteros y anular el recalculo de saldos, bien con el campo NO_CAL_SAL o bien con una variable que anule el recalculo.
El tema de recalculo de saldos, cuando hay volumen de apuntes a mi me lo hace bastante lento.
Si quitas los contiguos no recalcula el saldo ya que no evalua el if. El efecto viene a ser el mismo.
Con cosas masivas, lo mejor es no calcular saldos y luego forzar un recalculo. Aunque creo que debería dársele una vueltecita al tema del recalculo y mejorarlo en la medida de lo posible.
O sea, que te pones a realizar pruebas de carga con las tablas de Velneo sin comprobar el código de los Triggers y además no compruebas el Inspector de errores cuando eliminas los campos Enlace a hermano contiguo.
En efecto, Paco Satué.
Si necesitas un bocazas para hablar de algo sin conocimiento y que a la primera de cambio se pone a decir idioteces en el foro, quedo a tu disposición.
Al menos tengo esa triste experiencia.
Y como es una experiencia repetida, debo ser además más bruto que un arao.
Ruego disculpas y a ver si la próxima vez me machaco los dedos con un martillo antes de abrir temas sin sentido en el foro con el agravante de no haber atendido en primero lo que me explicó Antonio Vela en su respuesta de soporte …
Perdón.
Muchas gracias por reconocer los errores que por supuesto cometemos todos y de los que se aprende siempre algo.
No es necesario pedir disculpas porque seguramente habrá muchos que lean este hilo y se sentirán identificados por haber actuado de la misma forma ante un problema que se empeñan en achacar a Velneo.
