Guardar o no guardar?

[YAcosta]

Nunca hice una prueba de rendimiento real esto.

Si tienes un dato calculado y sencillo ¿lo guardas o no? hablando de una tabla de decenas de miles de registros.

Por ejemplo, tengo el campo Cantidad y el campo Precio, ¿Guardarías el total de multiplicar Cantidad por Precio?

Yo no le he estado guardando y por consiguiente siempre debo hacer

Select Cantidad, Precio, Cantidad * Precio as Total From...

en vez de
Select Cantidad, Precio, Total From...

En el primer caso se hace una operacion, en el segundo es una lectura y entiendo que dependiendo de otros factores una u otra forma puede tener diferente velocidad, pero ¿en la mayoria de casos que convendria? Entiendo también que la velocidad repercute realmente si estas usando en tu Where un campo indexado o no, si el indice es ascendente o descendente, etc.

¿Alguien llego a comprobar esta cuestión?

[Waldo]

yo lo guardaria, justamente para que el motor de base de datos, no tenga que hacer la cuenta fila x fila, total no me cuesta nada agregar un campito mas a la base

[ssccaann43]

Hermano,

Considero que mientras más livianas sean tus consultas, más rápido obtienes respuestas.... Ciertamente no se vera afectado por 3000 Registros, pero cuanto tengas consultas con mas de 2 millones de registros donde estos deban realizar operaciones matemáticas y luego mostrarlas como un  campo, créeme tardarán mas... Nada te pesa almacenarlas, de igual manera aunque es un campo calculado, no será molestia si lo almacenas...

[YAcosta]

yo lo guardaria, justamente para que el motor de base de datos, no tenga que hacer la cuenta fila x fila, total no me cuesta nada agregar un campito mas a la base

Claro, pero es una presunción, yo queria saber si alguien ya tuvo la experiencia mas alla del supuesto para saber ¿cual es el mayor costo? la "cuenta" de fila x fila que se traduce en un tiempo X o el espacio que ocupa/velocidad de lectura, etc. Ademas que con un SP esa operacion es muy veloz... pero nada, estoy en la misma presuncion puesto que no hice una prueba de rigor.

En esencia no es un tema que me quite el sueño, no me urge, igual si seria interesante leer sobre una experiencia sobre esto...y ademas que indique con que motor hizo la prueba y con cuantos registros. Seria interesante.

EDITO: Mientras escribia Miguel respondio.

[YAcosta]

Hermano,

Considero que mientras más livianas sean tus consultas, más rápido obtienes respuestas.... Ciertamente no se vera afectado por 3000 Registros, pero cuanto tengas consultas con mas de 2 millones de registros donde estos deban realizar operaciones matemáticas y luego mostrarlas como un  campo, créeme tardarán mas... Nada te pesa almacenarlas, de igual manera aunque es un campo calculado, no será molestia si lo almacenas...

Ok, son dos puntos a favor de guardarlas. Solo que un detalle, NO ES POR NECEDAD ACLARO, no defiendo ninguna posición, mi intención es dilucidar esta inquietud nada mas:
No creo que se haga una consulta contra 2 millones de registros, me explico. Si consulto contra 2 millones (Select * from MiTabla) EFECTIVAMENTE seria muy ineficiente hacer el calculo asi sea en SP, pero que reporte o grid te soporta eso, o sea, me resulta muy extraño que alguien consulte a una tabla de 2 millones sin hacer ningún Where, en el where usamos los indices y la operación de calculo se realiza después de que se filtro, salvo que alguien me demuestre que no es asi, hasta donde se los wheres se procesan antes que los selects, por tanto la multiplicacion en si se realizaria sobre el resultado... entonces ¿convino guardar los resultados?
Ademas hay que recalcular el campo Total si es que modificas Cantidad o Precio, aunque se resuelve con un trigger igual me sale a cuenta multiplicar en la consulta.

Sigamos departiendo.

[YAcosta]

Aqui encontre un post del cual me puedo valer para argumentar el orden de ejecucion de una consulta:

( 8 )          SELECT  (9)  DISTINCT (11)  <TOP_specification> <select_list>
( 1 )          FROM <left_table>
( 3 )          <joint_type> JOIN <right_table>
( 2 )          ON <join_condition>
( 4 )          WHERE <where_condition>
( 5 )          GROUP BY <group_by_list>
( 6 )          WITH {CUBE | ROLLUP} 
( 7 )          HAVING <having_condition>
(10)        ORDER BY <order_by_list>

Primero el From, luego los joins, despues todavía el where y en octavo posición el select que es donde haria la operacion, o sea, al resultado... si mi tabla tiene 2 millones y mi consulta me arroja 70 registros a los cuales multiplicare sus dos campos ¿para que guarde la multiplicacion?

EDITO: No hay puesto la fuente de este ordenamiento

[ssccaann43]

Un detalle importante estimado Yvan... Por experiencia propia...

Hace un par de años desarrolle un software para una agencia de viajes, el cual trata sobre Presupuestos y Forecast...

Presupuesto es simple, el usuario registra lo que presume que gastará en el año... de igual manera el usuario registrará lo que presume venderá en el año... Hasta allí vamos bien... Pero estamos hablando de más de 30 Usuarios registrando todo lo que va a gastar en el año, imagínate la cantidad de registros...

El Forecast no es más que un estudio que se aplica al presupuesto donde basado en el día a día, en la situación país, en la situación a nivel mundial, la economía, etc... El usuario decide cual gasto puede ahorrarse, cual no, cual ejecuta antes de tiempo, cual mueve a través de los meses, etc...

Posteriormente hace un comparativo según lo REAL(Que viene de un sistema administrativo-contable, el mes que se esta cerrando contablemente) y lo Forecasteado(Que viene del presupuesto inicial, pero con las modificaciones de los ahorros, movimientos, etc...)...

Esto no termina allí... La parte más dificil, que es el punto clave de tu post, es que al cerrar el MES contable, el sistema de presupuesto, debe hacer lo mismo, con ciertas formulas ya que para estimar un estado de PROFIT & LOST (GANANCIAS Y PERDIDAS), debemos considerar todo el universo, es decir, unir las Unidades o Departamentos que nos Generan Ingresos y aquellas que solo nos generan gastos, para ver como estuvo el mes...

Esta operación la realice mediante Stored Procedure en SQL Server 2008 R2, resulta que la empresa cuenta con 30 Departamentos o más, imaginate que cada Stored Procedured por unidad o departamento se me tardaba como 30 Seg, ahora bien, realizarlo una por una, era como mucho para que el usuario esperara que el sistema terminara de hacer ese cierre... En fin, esto logre solventarlo usando JAVA, ya que esta poderosa herramienta con su uso de MultiHilos, me permitía dispararle al SQL Server ejecuciones multiples y realizaba los cálculos con mayor velocidad...

Por ello te digo, mientras más puedas simplificarte las cosas, mejor... Nunca sabes cuando un calculo por BD puede joderte la vida...!

Saludos

[YAcosta]

Naturalmente la respuesta que se de no es algo definitivo, siempre habran factores que determinan usar una u otra opción: regla de negocio, complejidad de la consulta, etc. Es mas, cuando se trata de reportes legales si almaceno los resultados porque hay un documento contable vinculado. La cuestión iba mas a situaciones genéricas, si nos vamos al detalle de cada complejidad particular efectivamente no tendremos la misma respuesta e incluso se podria decir que hasta el post esta demas, pero para la mayoria de casos y de un cierto nivel de complejidad moderado de consultas como que si podemos aplicar un criterio similar.

+/-

tengo sed, voy por chela

[ssccaann43]

Ciertamente concuerdo contigo....! A donde invitas la chela? jaja

[wolf_kof]

Bueno hay algo en bases de datos que se llaman consultas(Vistas), Funciones, Trigger's, Eventos, que te pueden hacer mucho más facil el manejo de estas cosas, por ejemplo:

Para sumar dos campos de tu tabla en un tercer campo pudes hacer una función que se valla ejecutando por cada registro que vallas guardando dentro de la base de datos, sin que tu lo hagas en tu codigo de desarrollo, pero hay va ha estar.

[YAcosta]

Asi es, eso lo comente aqui, sigamos disparando.

[YAcosta]

Ya esta, estuve casi todo el dia indagando sobre este tema de puro curioso. Conseguí una respuesta que me satisface al 100% para los casos mas generales.

Los valores computados NO SE GUARDAN en la base de datos si es que hablamos de un motor serio. La respuesta y solución lo encontré con Firebird y si con Firebird se puede seguro que con los otros motores serios también.

Lo que se hace es crear una columna computada que no almacenará datos sino la definición.
Cito:
¿Qué es una columna computada?
Una columna cuyo contenido depende de otras columnas, previamente definidas.
¿Para qué se usan las columnas computadas?
Para poder referenciar a los datos de varias formas, o sea que los datos pueden encontrarse en sus columnas originales o en las columnas computadas. También para escribir fórmulas que estén siempre accesibles.
¿Cómo se declara una columna computada?
Con la cláusula COMPUTED BY

Luego se trata a esa columna de SOLO LECTURA con un select normal como si de una columna real se tratase. No es necesario tampoco crear un trigger y la chamba la hace el motor, no hay que hacer las operaciones simples por el lado del aplicativo. También sirve para usar concatenación de nombres y apellidos con todo y comas.

1. Las columnas computadas (casi) no ocupan espacio en la Base de Datos

¿Por qué? porque solamente se guarda la definición de la columna computada, no sus valores. Por ejemplo, si tu columna computada realiza alguna operación matemática entonces podrá ser de tipo BIGINT y ocupará 8 bytes. Nada más. Si la tabla tiene 1.000.000 de filas no se usarán 8.000.000 de bytes sino solamente 8 bytes, los de la definición.

2. En tus aplicaciones escribes menos
Si a tu columna computada la llamas, por ejemplo, TOTAL_VENTAS, entonces en tus stored procedures, en tus triggers, y en tu lenguaje de programación solamente necesitarás escribir TOTAL_VENTAS, no tendrás que estar multiplicando CANTIDAD * PRECIO en cada uno de esos lugares, así que ahorrarás escritura.

4. Si necesitas cambiar la fórmula, lo haces en un solo lugar
Supongamos que el resultado de CANTIDAD * VENTAS lo necesitas mostrar en 40 lugares distintos. Y después te dicen que hay que multiplicar a ese resultado por 1.1, para aumentarlo en un 10 %. Si no usas columnas computadas entonces tendrás que hacer 40 cambios (y quizás ni te acuerdes que son 40 y cambies solamente en 28, a pesar de que deberías haber cambiado en 40).

Usando columnas computadas no tendrás ese problema, ya que el cambio lo haces en un solo lugar (en la columna definida como COMPUTED BY) y automáticamente ya el nuevo valor estará disponible en los 40 lugares distintos.

Conclusión:
Usar columnas computadas es altamente recomendable porque ahorramos tiempo y ganamos en confianza y en seguridad. Escribimos menos y además si alguna vez necesitamos cambiar la fórmula lo hacemos en un solo lugar.

Fuente 1
Fuente 2

p.D: Seguro alguien dira: "Claro pues con eso se hace, con la funcion tal..." se me va a .... jajajja porque simplemente no lo dijo y es lo mismo que no saberlo (no mentira, si lo sabe pero no quería compartirlo), en todo caso yo desconocía el manejo de columnas computadas y creo no haber sido el único, siempre se aprende algo.

[Jeronimo]

Hola, Yván.
Perdón por la ignorancia.
A ver si entendí.
Si en una tabla tengo las columnas id (int), nombre (char), apellido (char), calle (char), etcétera, para consultar el apellido y el nombre con el formato 'apellido, nombre' habitualmente en MySQL hago así: "SELECT id, CONCAT(apellido, ', ', nombre) FROM clientes".
¿Con esta columna computada lo que conseguís es darle solo el formato 'apellido, nombre' de manera que en un "SELECT * FROM clientes" te traiga todas las columnas normalmente y en la columna computada traiga 'apellido, nombre' (con los valores de cada registro, obviamente)?
Si es así, es muy bueno.
Gracias por compartir la información.
Saludos.

Jerónimo

[YAcosta]

Si, exactamente asi es. lo tratas como una columna mas.

O sea, Select * Alumnos te da esto



y el ultimo es campo computado, en el no puedes actualizar directamente ya que ese campo depende de los otros dos. Acabo de probarlo y va de 100, incluso modificas algo en el campo nombre y ya cambia en el campo computado.
Si quiero la lista de todos los nombres completos solo haria: Select ALU_APENOM from Alumnos y ya.

También probé con artimetica para campos numericos que es lo que mas me interesa y va perfecto.

[wolf_kof]

Eso en mysql se llama función y en access campo calculado, pense haberlo explicado

Enviado desde mi HUAWEI P6-U06 mediante Tapatalk