Hola a tod@s

Estoy algo oxidado, me ayudan.

Necesito:
Necesito obtener solo la diferencia de los importes de ambas tablas, osea el total de los importes de dos tablas, lo explico:

Base de datos:
SQLite

Definición de las tablas:
Tabla1, nombre "Ingresos" con campos:
Descripción = Describe o es la denominación u origen del ingreso
Importe = El dinero ingresado
Cuenta = Es digamos una descripción de a donde se va almacenar ese ingreso
Realizado = Es la fecha del ingreso efectivo

Tabla2, nombre "Gastos" con campos:
Descripción = Describe o es la denominación u origen del gasto
Importe = El dinero gastado
Cuenta = Es digamos una descripción de donde se va a retirar el gasto
Realizado = Es la fecha del gasto efectivo

A tener en cuenta:
1. Campo Realizado es igual al año actual (2020), algo como strftime('%Y', Gastos.Realizado) = '2020' en ambas tablas
2. Campo Realizado <> "" en ambas tablas
3. Campo Cuenta = "Banco X" en ambas tablas
4. Los importes en ambas tablas están en positivo aunque existen importes negativos pero es para devoluciones, osea, para ponerse a 0
5. Cada tabla se ocupa de guardar Gastos o Ingresos, lo que necesito es restar Ingresos - Gastos y obtener su total.


Gracias de ante mano

==== Solución ===============

Hola, si querés sumar todos los ingresos t1 y restarlo a todos los gastos t2 podrías usar algo como esto.
Estas sentencias agrupan los gastos por cuenta y los ingresos, también por cuenta. luego haces una tercera sentencias para las restas y ya tenes el balance por cuenta.
también se puede hacer sin segregar por cuenta y obtenés el total de gastos y de ingresos.
Saludos.

(06-08-2020, 13:44)tincho escribió: Hola, si querés sumar todos los ingresos t1 y restarlo a todos los gastos t2 podrías usar algo como esto.

Código:

CREATE VIEW `ingreso` AS SELECT
    Cuenta,
    total(Importe) As Ingreso
    FROM Ingresos
GROUP BY Cuenta
;
CREATE VIEW `gasto` AS SELECT
    Cuenta,
    total(Importe) As Gasto
    FROM Gastos
GROUP BY Cuenta
;

Estas sentencias agrupan los gastos por cuenta y los ingresos, también por cuenta. luego haces una tercera sentencias para las restas y ya tenes el balance por cuenta.
también se puede hacer sin segregar por cuenta y obtenés el total de gastos y de ingresos.
Saludos.

La verdad que no había realizado nunca un create view. Me quedo indicarte que estoy haciendo la simulación con las herramientas de Conexiones de Gambas y no se si se puede implementar lo que me propones. Como deduzco que sabrás que yo sé hacer esto por programación pero mi intensión es hacerlo todo desde SQL y con SQL así como desde la herramienta de conexiones desde Gambas.

¿Esto lo ves posible hacer con la herramienta de conexiones de Gambas?

Por otra parte es posible si cumple todo tu propuesta, indicarme la tercera sentencia SQL para obtener la resta de tu dos consultas es que como ya te he dicho no lo he manejado nunca.

Para terminar me lo des o no, me indiques mas o no, Gracias.

Saludos.

Nota: Estoy haciendo esto, pero tengo que comprobar si funciona con los datos que tengo:

Gambafeliz: Hagamos algo mejor, subí un pequeño archivo sqlite con datos simulados que permitan hacer la consulta. Luego hago en este la consulta y lo devuelvo.
También se puede poner la consulta usando el icono de código geshi indicando SQL
Esto es un consejo que te doy para que obtengas mejores resultados, pero de todas mneras te dejo un ejemplo de como seria la tercera consulta.
Saludos.

(07-08-2020, 11:25)tincho escribió: Gambafeliz: Hagamos algo mejor, subí un pequeño archivo sqlite con datos simulados que permitan hacer la consulta. Luego hago en este la consulta y lo devuelvo.
También se puede poner la consulta usando el icono de código geshi indicando SQL
Esto es un consejo que te doy para que obtengas mejores resultados, pero de todas mneras te dejo un ejemplo de como seria la tercera consulta.

Código:

CREATE VIEW `totals` AS SELECT
        Cuenta,
        total(ingreso.ingreso - gasto.gasto) as balance
        from Cuentas
LEFT JOIN ingreso ON Cuentas.Cuenta = ingreso.Cuenta
LEFT JOIN gasto ON Cuentas.Cuenta = gasto.Cuenta
ORDER BY Cuentas.Cuenta;

Saludos.

Hola, tincho

He ejecutado las dos anteriores vistas "ingreso" y "gasto" así como esta última. Las dos primeras vistas todo bien. Pero la tercera vista, osea, "totals" me dice que la columna Cuenta es ambigua. Preguntas:

1. No se resolver la primera duda que te planteo, osea lo de ambiguo.

Por favor, ¿me ayudas?

Gracias.

gambafeliz, intenta preparar un pequeño ejemplo que funcione hasta donde alcances, si puede ser que cree automáticamente las bases de datos y las llene con datos ficticios. Luego pasa el proyecto por aquí como adjunto para poderlo examinar. Yo no soy muy bueno con bases de datos, pero al menos podría identificar algún fallo en el proceso o en las consultas. 

Por cierto, lo de columna ambigua significa que en la consulta no has escrito un cualificador para distinguir a qué columna con nombre duplicado en las dos tablas te refieres. Si tienes un campo "total" en ambas tablas, cuando haces operaciones tipo join o union, etc, necesitas cualificar con el nombre de tabla delante y un punto para cada campo, si no, hay ambigüedad y el sistema no sable a qué tabla te refieres. Por ejemplo, ingresos.total o gastos.total o Cuentas.Cuenta en tu caso concreto.

Por otro lado, estoy casi seguro de que nadie utiliza el gestor de bases de datos de gambas, yo al menos no lo veo muy "indicado". Mi consejo es que piques código a mano por dos motivos, uno es que tienes el control absoluto de lo que haces sin terceras partes y segundo, que así es como mejor se aprende a manejar BDs.

Saludos

(08-08-2020, 18:26)jguardon escribió: gambafeliz, intenta preparar un pequeño ejemplo que funcione hasta donde alcances, si puede ser que cree automáticamente las bases de datos y las llene con datos ficticios. Luego pasa el proyecto por aquí como adjunto para poderlo examinar. Yo no soy muy bueno con bases de datos, pero al menos podría identificar algún fallo en el proceso o en las consultas.

Me pondré a ello.
 

(08-08-2020, 18:26)jguardon escribió: Por cierto, lo de columna ambigua significa que en la consulta no has escrito un cualificador para distinguir a qué columna con nombre duplicado en las dos tablas te refieres. Si tienes un campo "total" en ambas tablas, cuando haces operaciones tipo join o union, etc, necesitas cualificar con el nombre de tabla delante y un punto para cada campo, si no, hay ambigüedad y el sistema no sable a qué tabla te refieres. Por ejemplo, ingresos.total o gastos.total o Cuentas.Cuenta en tu caso concreto.

Es que con todo respeto a tincho, me parece que la tercera consulta de tincho esta mal. Me explico y te lo explico. Si analizamos la consulta 1 y 2 crea 2 vistas a partir de la consulta Tabla: Ingresos (vista 1) y la consulta Tabla: Gastos (vista 2) y esta bien, sin comentarios por mi parte.

Pero la tercera vista para mi esta mal. Crea una vista a partir de una tabla que yo no he dado, osea, la tabla Cuentas, da la casualidad que existe en la base de datos pero no tiene nada que ver para los datos que he dado en el título de esta consulta, por lo tanto, quiere obtener datos a partir de una tabla y campos inexistentes.

Esto es lo que yo creo a no ser que lo explique el o tú.

(08-08-2020, 18:26)jguardon escribió: Por otro lado, estoy casi seguro de que nadie utiliza el gestor de bases de datos de gambas, yo al menos no lo veo muy "indicado".

Yo tengo una manía de programador y lo llevo al extremo a mundo real. Nunca busco ni uso nada que ya tengo en el fabricante original, mi tendencia es adaptarme. De esta forma optimizo los recursos, y nunca duplico recursos. Tiendo a explotar al máximo todo lo que me rodea. Te pongo un ejemplo, veo miles de personas que compran un móvil o una computadora y después compran x programas para hacer algo que el sistema operativo Android o Windows lo hace de forma nativa, pero la gente empieza por lo que le cuentan en una página de internet o amigo, pero nunca parten desde el fabricante nativo del sistema operativo. Esto para mi es incultura, lo mismo pasa por ejemplo cuando arreglas por ejemplo el suelo o paredes de tu casa, hay profesionales por decir algo, yo les llamo chapuzas, que no conocen los materiales y usan técnicas y materiales de los años 60 y nunca se preocuparon de ver los materiales y sistemas actuales para hacer algo perfecto en vez de malo o mediocre. En fin, soy un maldito proteccionista. Normalmente soy tan fiable que trabajos hechos por mi cualquier persona que me los pida puede quedarse completamente tranquilo de no tener que revisar nada.

(08-08-2020, 18:26)jguardon escribió: Mi consejo es que piques código a mano por dos motivos, uno es que tienes el control absoluto de lo que haces sin terceras partes y segundo, que así es como mejor se aprende a manejar BDs.

Serias tan amable de explicarme esto, no lo he entendido. Te cuento en que sentido, "piques código a mano" te refieres a que sume los importe desde programación. Por que esto ya lo hago y funciona. Pero mi intensión es obtenerlo desde SQL, para mi es muchísimo mas perfecto. Como explico arriba, hablar con la BD directamente y obtener resultados directo es como tener un enanito dentro donde le dices dame esto y tan fiable como que ese enanico es la pera para darte todo.

Para resumir no me entero de lo que dices en esta parte última, ¿me lo matizas con toda claridad?, para mi es importante poder entenderte.

Gracias

(08-08-2020, 20:29)gambafeliz escribió: piques código a mano

Picar código es escribirlo, teclearlo, programar en definitiva. En contra de usar un gestor que haga operaciones sin escribir código, eso es más o menos lo que trataba de explicar.

Con respecto a los códigos publicados en el hilo, no tengo la menor idea de dónde provienen, si son ejemplos reales o son supuestos, sin ver la estructura real  de las bases de datos es difícil evaluar el asunto. Pero en SQL podrás hacer eso y más, aunque sqlite tiene menos prestaciones que MySQL o Postgres, creo que es más que suficiente para lo que quieres.

Lástima que no tengamos por aquí al gurú de las bases de datos, nuestro querido shordi...

Saludos

(08-08-2020, 21:24)jguardon escribió:

(08-08-2020, 20:29)gambafeliz escribió: piques código a mano

Picar código es escribirlo, teclearlo, programar en definitiva. En contra de usar un gestor que haga operaciones sin escribir código, eso es más o menos lo que trataba de explicar.

Con respecto a los códigos publicados en el hilo, no tengo la menor idea de dónde provienen, si son ejemplos reales o son supuestos, sin ver la estructura real  de las bases de datos es difícil evaluar el asunto. Pero en SQL podrás hacer eso y más, aunque sqlite tiene menos prestaciones que MySQL o Postgres, creo que es más que suficiente para lo que quieres.

Entendido

(08-08-2020, 21:24)jguardon escribió: Lástima que no tengamos por aquí al gurú de las bases de datos, nuestro querido shordi...

Saludos

Sí, sin duda. Cuanto hecho de menos a Shordi, lo conocí poco pero lo suficiente para recordarlo. Lastima me gustaría poder conversar con personas tan geniales e inteligentes como el. Con esto no quiero decir que nadie de aquí en el foro no lo sea de igual modo. Solo que Shordi me mola y es muy afín a mi personalidad.

Oye gracias por todo.