Visual Basic Foro
Programación => Bases de Datos => Mensaje iniciado por: YAcosta en Junio 17, 2014, 01:11:44 pm
-
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?
-
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
-
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...
-
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.
-
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.
-
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 (http://social.msdn.microsoft.com/Forums/es-ES/d7b3d59f-3054-4ecd-b1c8-3fdba0ac5b94/orden-de-ejecucin-en-clausula-where?forum=sqlserveres) de este ordenamiento
-
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
-
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
-
Ciertamente concuerdo contigo....! A donde invitas la chela? jaja
-
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.
-
Asi es, eso lo comente aqui (http://leandroascierto.com/foro/index.php?topic=2590.msg14196#msg14196), sigamos disparando.
-
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 (http://firebird21.wordpress.com/2013/06/23/columnas-computadas/)
Fuente 2 (http://firebird21.wordpress.com/2014/06/17/utilizando-columnas-computadas/)
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.
-
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
-
Si, exactamente asi es. lo tratas como una columna mas.
O sea, Select * Alumnos te da esto
(http://firebird21.files.wordpress.com/2013/06/computed1.png?w=765&h=117)
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.
-
Eso en mysql se llama función y en access campo calculado, pense haberlo explicado
Enviado desde mi HUAWEI P6-U06 mediante Tapatalk
-
Excelente, Yván. ¡Qué útil!
Muchas gracias.
NDWgt: ¿Podrás poner un ejemplo o una breve indicación de cómo se crea esto en MySQL, por favor?
Muchas gracias.
Jerónimo
-
NDWgt: ¿Podrás poner un ejemplo o una breve indicación de cómo se crea esto en MySQL, por favor?
Muchas gracias.
Mmmmm me suena a desafio pero hay va.
Esto es una función, que la debes de incluir en una consulta, mmm a mi parecer a mi me basta.
SELECT
`Nombre`
, `Apellido`
, CONCAT(`Nombre`," ",`Apellido`) AS NomApe
, CONCAT(`Apellido`,", ",`Nombre`) AS ApeNom
FROM
`lisbeth`.`ejemplos`;
Esto es un Trigger que puedes crear para hacer eso mismo pero en la tabla
DELIMITER $$
FOR EACH ROW
BEGIN
set new.`NomApe` = concat(new.`Nombre`, space(1) , new.`Apellido`);
END */$$
DELIMITER ;
DELIMITER $$
FOR EACH ROW
BEGIN
set new.`ApeNom` = concat(new.`Apellido`, `,`, space(1) , new.`Nombre`);
END */$$
DELIMITER ;
Y psss espero haber pasado la prueba XD
-
Doc, lo que te pidio Jeronimo no se logra con lo que tu expones.
El primer query haces una concatenación tal y como lo puso Jeronimo y viene siendo un armado en el Select.
En el segundo query es lo mismo pero esta vez escribes en la tabla (creo que esta incompleto, no estoy seguro)
Con respecto al Campo Calculado de Access en realidad es un Query que se invoca pero no es un campo por decirlo "virtual". En todo caso lo de Access se aproxima un poco pero no es lo mismo, tengo la esperanza de que alguien nos comente una cuestion similar con MySQL y porque no con otro motor tambien.
Lo que Firebird hace es crear una Columna Computada en la MISMA tabla que luego puedo invocar con un select sencillo a dicha tabla y no verme obligado a ejecutar un query especifico como lo hace Access o escribir un trigger que finalmente mete datos en la tabla y con eso se aleja mas a la comparativa.
No creo que pasaste el desafio Ariel.
-
Vamos por partes.
Mmmmm me suena a desafio pero hay va.
No era un desafío. Hay miles de cosas que todavía no aprendí sobre bases de datos. Para ser más concreto, índices, triggers y procedimientos almacenados son cosas que todavía estoy investigando. Soy principiante.
Gracias por la exposición.
Doc, lo que te pidio Jeronimo no se logra con lo que tu expones.
El primer query haces una concatenación tal y como lo puso Jeronimo y viene siendo un armado en el Select.
En el segundo query es lo mismo pero esta vez escribes en la tabla (creo que esta incompleto, no estoy seguro)
Con respecto al Campo Calculado de Access en realidad es un Query que se invoca pero no es un campo por decirlo "virtual". En todo caso lo de Access se aproxima un poco pero no es lo mismo, tengo la esperanza de que alguien nos comente una cuestion similar con MySQL y porque no con otro motor tambien.
Lo que Firebird hace es crear una Columna Computada en la MISMA tabla que luego puedo invocar con un select sencillo a dicha tabla y no verme obligado a ejecutar un query especifico como lo hace Access o escribir un trigger que finalmente mete datos en la tabla y con eso se aleja mas a la comparativa.
No creo que pasaste el desafio Ariel.
Yván, me ahorraste el comentario. Gracias por explicarlo tan claramente.
Jerónimo
-
Solo por pura casualidad están seguros que es lo que acaban de contestar!!!!!!?????
YAcosta te has preguntado la definición de un campo calculado en firebird que es?
Les parece bien documentarse mejor en este tema?
LAs querys no son en el desarrollo (NO ESTAN DENTRO DE VB) estan dentro de MySql, en la primera es una consulta dentro de mysql que al ser llamada como una tabla ya me muestra los campos calculados, sin que estén fisicamente en la tabla, la segunda es exactamente lo mismo solo que llamo a la tabla de origen sin consulta y aparecen los campos (Por Arte de Magia) al llamarlos con una consulta select. En las dos queys están en memoria, ninguna almacena absolutamente nada (SON VIRTUALES).
Es más los Trigger son tan poderosos que pueden no solo calcular por registro si no por grupos de registros.
Link para documentación:
http://dev.mysql.com/doc/refman/5.0/es/using-triggers.html (http://dev.mysql.com/doc/refman/5.0/es/using-triggers.html)
Lo único que es código SQL dentro de la base de datos, haaaa claro no está en un campo y me da para meterle una expresión como en firebird. Eso depende del IDE que utilices.
-
Tranquilo no te ofusques ¿que te pasa?¿sientes de nuevo ser atacado? sereno papa que recien estoy aprendiendo a manejar...
https://www.youtube.com/watch?v=IIjIiegr4nY
Cuando defines (captas?) a una columna como COMPUTED BY puedes poner en esa columna cualquier fórmula matemática o concatenación que desees o inclusive puedes usar cualquier función del Firebird (Sorry por usar esa palabra fea).
En la tabla solamente se guarda la definición de la columna.
Lo que no entiendes y ahora te lo explico mas despacito es que esa columna computada se crea EN LA TABLA, no la tienes que ejecutar en cada query, es una bondad del motor!!!. Incluso, al ver la estructura de la tabla ves el campo computado como si fuera una columna mas PERO al que no le puedes meter datos a mano.
¿entonces es un trigger?
Te diré (no te asustes) que de verdad no sé cual es la estructura interna de los campos computados que no pasa de ser una definición de tabla, pero seguro que no es un trigger, porque los triggers se usan para operaciones de inserción, actualización, borrado, se aplican before o after... en cambio los campos computados se usan solamente para las consultas (¿quieres que me documente mas? mañana ya?)
Creo que el gran meollo para ti y de alli tu confusión y bueno mi error fue no aclararte porque "pensé haberlo explicado" es que el Campo Computado de Firebird no es igual al Campo Calculado de MySQL. En realidad "Campo Calculado" no es una expresión propia de MySQL sino de la sintaxis SQL en general (incluso de Firree.. firr, ya tu sabes).
Sobre tu cuerito.
En tu primer query que es común y silvestre que tiene dos campos concatenados y que lo usaste para dos campos calculados son el resultado del query en si, es como precio * cantidad as Total que pongo en cualquier select. y cierto todo eso esta en memoria y todo el rollo, eso pasa con cualquier motor.
Entonces ¿como creas el campo computado para hacer la consulta asi en MySQL? Pues no hay, en todo caso yo no lo he encontrado y me parece que tu tampoco, quizá luego lo encuentres cuando te documentes.
De momento ejecutas el select con tu campo calculado como todos los demás motores o soplarte un trigger (mentira, todos los demás no, me falta documentarme, de momento no lo he encontrado en MySQL ni en Access pero si en SQL Server, en SQL Server es exactamente la misma lógica que FB solo que su definición es aun mas sencilla).
¿Los trigger son poderosos? gracias por ese dato, no tenia idea.
Y la ultima linea no te entendí, tampoco lo expliques, voy a documentarme mas para poder entenderte.
P&L
-
Creo que me sobrepase YAcosta, pido perdón por ello, anoche andaba de fiesta!
Por favor omitan semejante comentario y en la forma que lo hize.
Enviado desde mi HUAWEI P6-U06 mediante Tapatalk
-
Creo que me sobrepase YAcosta, pido perdón por ello, anoche andaba de fiesta!
Por favor omitan semejante comentario y en la forma que lo hize.
Enviado desde mi HUAWEI P6-U06 mediante Tapatalk
Sin rencores. Siempre es bueno dar y recibir... mmm... ayudar y recibir ayuda, siempre que sea en buenos términos y con buena intención.
Gracias a ambos por la información.
Saludos.
Jerónimo
-
Muy interesante, busqué y en Ms SQL Server, también se llama campo calculado.
Pero aunque quede mas prolija la tabla, o los SELECTS, supongo que en el momento de obtener los datos el motor debe hacer la cuenta de la misma manera que si pondriamos CANTIDAD * PRECIO, no afectará esto en una tabla grande?
-
Creo que me sobrepase YAcosta, pido perdón por ello, anoche andaba de fiesta!
Por favor omitan semejante comentario y en la forma que lo hize.
Enviado desde mi HUAWEI P6-U06 mediante Tapatalk
Esta bien bro, igual me disculpo contigo por la posición revanchista. Esta wada pasa porque personalizamos el tema y no hay chela en medio. :-)
Saludos
-
Muy interesante, busqué y en Ms SQL Server, también se llama campo calculado.
Pero aunque quede mas prolija la tabla, o los SELECTS, supongo que en el momento de obtener los datos el motor debe hacer la cuenta de la misma manera que si pondriamos CANTIDAD * PRECIO, no afectará esto en una tabla grande?
No sabría decirte con seguridad si es mas veloz hacer un select del "campo computado" VS un "campo calculado" (del que se hace en el select) pero presumo que seria igual.
La velocidad viene dada por los campos indices que usas en tu where ademas de otros factores . En el esquemita que puse arriba el campo select se evalúa todavía en la posición 8 y para eso ya tienes filtrada tu consulta y por ende la diferencia de velocidad del calculo sea por un método o por otro me parece que no seria significante. ¿Cuantos registros "manejables" obtienes después de una consulta? creo que incluso 10,000 registros como resultado es un absurdo y esa cantidad incluso no le hace problema ni al motor... y diría que ni al rs puesto que yo probe un query que me arroja 7000 registros para llenar un grid y vuela.
Al margen de la igual velocidad, hay otro factores que lo hacen mejor, como en SQL Server o Firebird el campo computado ya definido lo puedes invocar desde cualquier otro select, si tienes que modificar la formula solo modificas en ese campo computado, reduces margen de error por mantenimiento, si usaras calculado tendrías que buscas todos los querys donde debes modificar la formula, y si grabas el saldo en la tabla física tendrías que correr un query de actualización, sinceramente le veo mas ventajas. En conclusión me queda de todo esto que solo escribiré los saldos si es que hay documentos legales asociados y para todos los demás casos los computare hasta encontrar una mejor propuesta.
Saludos