Guardar o no guardar?

[Jeronimo]

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

[wolf_kof]

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.

Código: (SQL) [Seleccionar]

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

Código: (SQL) [Seleccionar]

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

[YAcosta]

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.

[Jeronimo]

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

[wolf_kof]

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

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.

[YAcosta]

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

[wolf_kof]

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

[Jeronimo]

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

[Waldo]

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?

[YAcosta]

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

[YAcosta]

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