Consulta SQL para varios campos

[Raynel]

Bueno la consulta se realizó con éxito, pero sería interesante conocer un método para muchos campos (lo admito lo desconozco), aunque no soy muy diestro en Delphi y sé solo lo básico de SQL, estoy aprendiendo; en el programa que estoy haciendo lo hago con tablas planas, en concreto Paradox. Gracias por el empujoncito jejejeje. Hoy si me acuesto temprano, no quiero pernoctarme y acostumbrarme al huso horario chino jejejejeje. Buenas noches a todos y suerte!!!!!.

[[Delphius]]

Empezado por Raynel

Bueno la consulta se realizó con éxito, pero sería interesante conocer un método para muchos campos (lo admito lo desconozco), aunque no soy muy diestro en Delphi y sé solo lo básico de SQL, estoy aprendiendo;

¿Que haz querido decir con eso?
¿Muchos campos? ¿Cúanto es mucho?
Realizar un SQL que en su parte where tiene demasiadas condiciones no es tan productivo. Más si se trata de Paradox. Cuanto más condiciones tengas, si bien filtrarás lo que no desees, el motor necesita de más tiempo para procesar.

Una SQL que incluya muchos campos... ¿a que quieres llegar? Eso me pregunto yo... De forma genérica se tiene:

Código SQL [-]
select tabla1.campo1, ... tabla2.campoN, ... tablaN.campoN
from tabla1, ... tablaN
where...

Si la consulta debe devolver 30, 40, 100 campos... (no registros) que los devuelva. Pero también una buena consulta SQL en su parte WHERE no debería tener más del 30 0 40% de los campos que intervienen en su parte SELECT.

Por lo general, no tiene sentido y significado alguno una consulta que:
1. Este formada por muchos campos, O bien.
2. Que implemente demasiados "filtros".

Esto es debido a que:
1. Los informes o consultas deben ser breves, resumidos. Un resumen no es algo que te muestra 30 campos.
2. Muchos filtros pueden hacer que se pierda de vista otros registros que si podrían ser considerados en la consulta.

En estos casos, sería recomendable partir la consulta en varias consultas parciales.

Considero que si explicas tu problema (la raiz de todo) vas a encontrar una respuesta más exacta.
Estoy adivinando... ¡Que deseas!

Saludos,

[Raynel]

Empezado por Delphius

Esto es debido a que:
1. Los informes o consultas deben ser breves, resumidos. Un resumen no es algo que te muestra 30 campos.
2. Muchos filtros pueden hacer que se pierda de vista otros registros que si podrían ser considerados en la consulta.

Tienes razón Delphius, para lograr una consulta eficiente se debe seguir lo anterior aunado a una buena interpretación de lo que quieres conseguir (obvio!!); solo imaginaba para una tabla que no contuviera no mas de 40 campos, aunque es mejor manejarlos por array y no una tabla; te explico, el programa que estoy haciendo toma ciertos números y hace un conteo que a su vez vuelve a hacer otro conteo de este último conteo (para resumirte un poco), y por ahí me largo con ecuaciones estadísticas y demás especias. Antes lo hice pero archivando estos números en un .dat, y ahora lo quiero hacer con tablas planas. Te comento que mi tabla no pasa de 12 campos. Y están ordenados por fechas (ya de ahí lo de ordenar será después). Espero que me ayuden en este proyecto, ya que incluirá exportar a un archivo Excel (he tomado unos tips del foro, los estudiaré más adelante). Este foro es una tremenda biblioteca de recursos.

[Raynel]

Empezado por Delphius

Esto es debido a que:
1. Los informes o consultas deben ser breves, resumidos. Un resumen no es algo que te muestra 30 campos.
2. Muchos filtros pueden hacer que se pierda de vista otros registros que si podrían ser considerados en la consulta.

Tienes razón Delphius, para lograr una consulta eficiente se debe seguir lo anterior aunado a una buena interpretación de lo que quieres conseguir (obvio!!); solo imaginaba para una tabla que no contuviera no mas de 40 campos, aunque es mejor manejarlos por array y no una tabla; te explico, el programa que estoy haciendo toma ciertos números y hace un conteo que a su vez vuelve a hacer otro conteo de este último conteo (para resumirte un poco), y por ahí me largo con ecuaciones estadísticas y demás especias. Antes lo hice pero archivando estos números en un .dat, y ahora lo quiero hacer con tablas planas. Te comento que mi tabla no pasa de 12 campos. Y están ordenados por fechas (ya de ahí lo de ordenar será después). Espero que me ayuden en este proyecto, ya que incluirá exportar a un archivo Excel (he tomado unos tips del foro, los estudiaré más adelante). Este foro es una tremenda biblioteca de recursos. Gracias a todos.

[[Delphius]]

Empezado por Raynel

Tienes razón Delphius, para lograr una consulta eficiente se debe seguir lo anterior aunado a una buena interpretación de lo que quieres conseguir (obvio!!); solo imaginaba para una tabla que no contuviera no mas de 40 campos, aunque es mejor manejarlos por array y no una tabla; te explico, el programa que estoy haciendo toma ciertos números y hace un conteo que a su vez vuelve a hacer otro conteo de este último conteo (para resumirte un poco), y por ahí me largo con ecuaciones estadísticas y demás especias. Antes lo hice pero archivando estos números en un .dat, y ahora lo quiero hacer con tablas planas. Te comento que mi tabla no pasa de 12 campos. Y están ordenados por fechas (ya de ahí lo de ordenar será después). Espero que me ayuden en este proyecto, ya que incluirá exportar a un archivo Excel (he tomado unos tips del foro, los estudiaré más adelante). Este foro es una tremenda biblioteca de recursos. Gracias a todos.

La mayoría de los motores cuentan con funciones estadísticas simples como ser media, varianza, además de las sumas, conteo, máximos, mínimos.

Los manuales SQL explican estos temas. Lee Raynel, lee... no importa la cantidad de los campos (12 es un valor aceptable).

por ejemplo:

Código SQL [-]
select AVG(campoA)
from tabla
where (algo)

devolverá el promedio del contenido de campoA que cumplan la condición Algo.

Necesitarías revisas que "especias" son las que realizas y corroborar que estén soportadas por Paradox, aunque yo no creo que disponga de mucho. Para cosas más elaboradas habrá que traer el conjunto de registros, almacenarlos en un array talvez, y pasarlo a una funcion hecha en Delphi.

Más no puedo decirte. Solo LEE.

Saludos,

[Raynel]

Gracias. eso haré.