que es más rápido query o filtrar tabla?
 

Hola amigos del foro, según yo, la query, pero me gustaría saber por que. Gracias por leer este hilo.

Suponiendo que la base de datos sea cliente servidor, será muchos más rápido la consulta, porque solamente traerá del servidor los registros que obtenga la consulta, es decir el tiempo de respuesta irá en proporción a los datos que obtenga.

Un Saludo.

si marcos es cliente servidor, ahora mi duda al hacer esto:

Código Delphi [-]
tabla.filtered := True;
tabla.filter = 'precio > 300';

al usar tablas (en este caso el componente ttable), el filtro trae solo los registrosfiltrados del servidor, o a todos?, o sea ttable siempre los trae a todos y después se filtran?.

Habría que ver las características de la base de datos con filtros, pero éstos generalmente lo que hacen es no mostrar los registros que no cumplen las normas de filtrado pero viajen todos por la red..

Un Saludo.

Así, mismo. Pues para poder filtrar debe tener el ttable Open con lo cual traes todos los regisotos, y despues filtrar.

Saludos

De acuerdo a eso, yo en la empresa que me inicie programando en delphi, tenían como política, abrir todas las tablas cuando se cargaba el data modulo. ahora de que estamos hablando de esto, eso era nefasto o no es tanto así?

Bueno, como dices es una "politica" de la empresa, pero de decirte de que si es una mala practica, pues para mi si lo es.

Yo prefiero SIEMPRE abrir o activar mis dataset cuando lo vaya a usar y liberarlo cuando ya no sea necesario tenerlos.

El hecho de tener todas las tablas abiertas desde el principio de la aplicación hasta el final, no tiene apenas penalización en el rendimiento, sino son muchas unas 50 a 70. La aplicación no tiene que estar todo el tiempo abriendo y cerrando tablas que también supone una baja en el rendimiento. El problema que veo es el riesgo, si se bloquea el ordenador y hay que apagarlo o se va la luz, al tener todas las tablas abiertas siempre puede corromperse alguna.

Un Saludo.

Quizá no consuma muchos recursos tener abiertas las tablas pero sí que se alenta el inicio de la aplicación si se abren todas al comienzo. Podría optarse por no cerrar las tablas sino hasta el término de la aplicación, pero abrirlas sólo la primera vez que se usen.

// Saludos

Yo salvo excepciones suelo optar por la opción que apunta Román, si son pocas tablas, no más de 40. Porque también el dejarlas cerradas tiene un problema que se nos olvide en el código fuente abrir una tabla que se utiliza poco y cuando el usuario va a realizar esa función obtiene una excepción.

Si están todas abiertas desde el principio uno tiene la seguridad de que no va a ocurrir este problema.

Un Saludo.

Esto, si se tiene la practica de tener todos los dataset en un Datamodulo. De lo contrario creo que lo mejor es abrir el dataset cuando se necesite, para que asi traiga los registros actualizados.

Saludos

Estoy contigo Vtdeleon, de hecho, ahora mismo uso ambas cosas, el Datamodule y datasets en los forms.

En el datamodule un bucle abre todos los datasets.
En las ventanas, heredo de una que abre el dataset principal al crearse, y cierra todos los datasets al cerrarse la ventana. Resulta tremendamente cómodo olvidarse de hacerlo a mano. Las consultas que deben abrirse en ciertas ocasiones, claro está, se abre cuando se necesite.

Saludos

No me acabo de aclarar con lo que dice Lepe .

Tienes en el DataModule , todas las tablas (supongamos que usamos la paleta BDE) , y en el form ¿Qué es lo que tienes ? ¿Tablas también ? ¿DataSource apuntando a una tabla?

en el datamodule un bucle abre todas las tablas ¿Qué tipo de función abre todas las tablas ,podrias ponerla?

Pero si estan todas las tablas abiertas , cuando se cierran y como ??

Sobre los Tquerys no pregunto , por que esto si parece claro , se abren y cierran cuando se necesiten .

Hola
Mi opinion como aprendiz es:
Usar solo el conector de la base de datos en el datamodule
Usar Tablas solo en caso extremadamente necesario o por comodidad
Usar Query o sentencias sql lo mas que se pueda.
A nivel de revision de codigo o forms es mucho mas facil cuando se tiene el componente (Table o Query) en el form, de esa manera me organizo y me funciona, que mas da tener cuantos componentes de tablas o querys quieras en el form, son invisibles y no me molestan.
Creo que es importante abrir y cerrar la tabla que no se este ocupando, realmente hace muy lento el programa si se tienen todas abiertas, el mio tiene mas de 50 y con mucha informacion, si abriera todas las tablas a la vez me tomaria todo el cafe de la cafetera antes de que el programa arrancara, no tengo tanta paciencia.:D
Que consuma recursos o no, la verdad no importa, cuanto vale el tiempo, si uno tiene todas las tablas abiertas y hay un bajo de tension se puede fastidiar la base de datos completa, para mi es un riesgo.
Por otra parte para David, la tabla trae toda la informacion que contenga, si es poca, usala, de otro modo te aconsejo, como lejitimo aprendiz, usar querys, son mas rapidas y seguras.
Saludos.

Es aconsejable tener todos los datasets en módulos de datos y no en los formularios. Por una parte, si en algún momento deseas cambiar de componentes (IBX por Fib, BDE por ADO, Zeos por MyDac, etc., etc.) la migración te será más sencilla; todos los formularios quedarán prácticamente sin cambios y únicamente tendrás que reemplazar componentes en lugares muy específicos que son los data module.

Por otro lado, la invisibilidad es realtiva. Ciertamente no son componentes que se vean en el formulario, pero sí en el código, que pronto se convierte en una mezcla de código visual para la interfaz de usuario, y código de negocios, la lógica de la aplicación. Llega un momento en que cualquier cambio, sea en la lógica o sea en la interfaz provoca efectos secundarios en la otra parte y el mantenimiento de la aplicación se hace muy pesado.

// Saludos

Estoy con Román, yo desde que salieron los DataModulos los he utilizado siempre en todas las aplicaciones.


Un Saludo.

yo uso DataModulos, a pesar que para muchos de mis procesos me he ido por las querys que son más rápidas y más versatiles, a pesar que para algunas cosas uso TTABLE.

Ya veo la idea , pones todas las tablas y todos los Querys en el DataModule , pones en el Form un dataSource y en codigo DataSource.DataSet.

Luego si quieres cambiar de base de datos , insertar otro DataModule , y pones las tablas y Querys con el mismo nombre que Tenian en el otro DataModule , eliminas el anterior DataModule y guardas el nuevo DataModule , con los componentes nativos de la nueva base de datos , con el mismo nombre .

De esa manera , puedes cambiar de base de datos , de una manera rápida y eficaz .

Lo que no me queda claro , es el momento , de abrir y cerrar tablas , en el DataModule , no es mejor abrir las tablas de cada formulario en el Evento TFormOncreate y cerrarlas en ondestroy ???

David dos cosas, abrir y cerrar te puede traer una preocupación más, y otra cerrar y abrir puede ser lento sobre todo en sistema cliente/servidor, por eso yo habro en el data modulo, y cierro solamente cuando cierro y aplicación, bueno ni hago eso, por que al cerrar la aplicación delphi cierra todas la tablas. Yo recomiendo el uso de querys. más fáil, más rápido, y totalmente portable.

Bueno, tiene sus pro y contras. Particularmente uso las dos técnicas de usar o no el Datamodulo. Dependiendo de la envergadura o el análisis que yo le haya hecho al futuro sistema.

La práctica de cada quien.

¿Cómo cuales?

No dudo que tengas razón, pero para ganancia del debate sería interesante conocer en qué casos la gente prefiere poner los datasets en los formularios.

// Saludos

Hola a todos.

Ahora mismo por necesidad del cliente, quiere tener varias ventanas abiertas de cliente, y en cada ventana quiere tener un cliente distinto. En esta situación no se pueden compartir los objetos TTable en un solo Datamodule, hay que poner las tablas y los datasources sobre el mismo Form, abrirlos al crear la ventana y cerrarlos al salir. También se ha comentado alguna vez el hecho crear un datamodule por cada Form que se tenga, así se independiza el acceso a dato de la interfaz (esto le gusta mucho a román ;)) para mí es demasiado.

Lo cierto es que uso un Datamodule general para configurar la conexión, objeto database, tablas y consultas que si se comparten con varias ventanas, (por ejemplo un listado de clientes ordenado alfabeticamente, etc), y todos ellos si se mantienen abiertos durante toda la ejecución del programa.

La rutina que abre los datasets:

Código Delphi [-]
    with dtm do
      for i := 0 to ComponentCount-1 do
      if components[i] is TDBDataset then
      with TDBDataset(components[i]) do
        Open;

Tanto el TTable como los TQuerys descienden de TDBDataset del BDE, por tanto tienen los métodos Open y Close. De hecho, el TTable no implementa el método Open (ni lo sobrescribe), sino que lo hereda de sus antecesores.

Ahora mismo trabajo con Firebird y MDO, no uso el BDE ni tampoco objetos TTable sino MDODatasets, pero bueno, para que se entienda lo puse así.

Saludos

Siendo un poco pesado: si separar la interfaz de usuario del aceso a datos es demasiado, entonces no hay más que decir: que se coloquen las componentes donde mejor nos parezca.

// Saludos

Saludos

Te escribiré de mi manera en particular.

Creo que Lepe ha dado un punto de el por qué uso dataset en los Forms Por lo regular desarrollo en FB, utilizando MDO y solo MDODataset (Ds). Cada formulario puede requerir uno que otro campo (uno, dos o todos), por tanto suelo tener "Ds" que solo traigan los campos y registros necesarios para mi consulta o transacción. Y preguntaras ¿Por qué no poner todo esos "Ds" en un Datamodulo?, pues para el simple hecho de no confundirme, no tener nombres similares o parecidos, además de tener todo centrado.

Pongamos un Ej. de un "Ds" que no dejaría solo en un Datamodulo: Tabla Empleados (Sis. Nóminas).

En este necesitamos un Formulario de registro de Empleados, para lo cual necesitaremos todos los campos de la tabla Empleado; otro formulario solo para consultar quienes cumplen año en un determinado Mes; otro para consultar sus ingresos y/o prestaciones; y así sucesivamente. Como puedes ver, los dos últimos formularios solo necesitan ciertos campos, no todos.

En un Datamodulo suelo agregar MDODatabase, Transaction, ciertos objetos no visuales como el TImageList y rara vez un "Ds" como la tabla de Usuario (por decir uno fácil).

El mantenimiento seria duro, engorroso, devastador; Cambiar de DB descomunal. No existe un Sistema Ideal.

Con respecto al tiempo en que duraría la aplicación en iniciar, esto es relativo.

Dataset en Datamodulo: Cada vez que se inicia la aplicación tarde un poco mas en estar "ready" porque esta creando los Objetos que se encuentran el en Datamodulo. Ganando un poco mas de rapidez cada vez que creas un formulario.

Dataset en Forms: Viceversa.

PD: :rooleyes: Quede claro que es la manera en como lo veo, Personal. Y como es así, podría tener un punto de vista o algunos conceptos erróneos, por lo que podría cambiar si es para mejorar :D .

Pd: No soy muy bueno expositor:(.

Supongo que la mayoría de nosotros, durante el inicio de la aplicación usamos un SplashScreen, como original que soy, :D incluyo el logo de la empresa con Transparentcolor a true y si acaso un ProgressBar debajo.

Seamos realistas, a las empresas les encanta ver su logotipo en un programa, y si lo presentas bonito, mucho mejor ;). Eso si, jamás uso un Timer para que se detenga un tiempo, y si alguna vez he de hacerlo, no creo que supere 1.5 segundos.

roman, creo que no me expresé con claridad. Respeto tu opinión y sé que vas muy por delante de mi, quizás lo vea de otra forma dentro de un tiempo. Ahora mismo "me parece demasiado" el trabajo que, a mi entender, supone el crear dinámicamente las ventanas,y además crear el Datamodule asociado; quizás uses alguna técnica que simplifique los pasos. Tal y como yo lo he interpretado, sería crear la ventana y en el FormCreate, crear el DAtamodule, asignándole el Padre para que se libere al cerrar la ventana.

Ahora mismo, aún trabajando con 2 monitores, me falta espacio para el IDE y las ventanas que diseño, si incluyo un Datamodule por cada Ventana, (pueden ser perfectamente más de 60), me volvería tarumba (es que soy muy flojo ;)).

Tampoco he tenido que actualizar los componentes de BBDD a otro motor, y sé que en ese caso me tocaría casi realizar la aplicación de nuevo... simplemente rezo para que no llegue ese momento :D.

Antes jamás usaba objetos, POO, ni DUnit, ahora para mí es una religión, por eso no quisiera que te molestase si alguna vez difiero de tí, reitero, para mi es un honor leer tus opiniones y comentarios.

Saludos

No le veo sentido para hacer eso:confused:

Saludos

Eso creo que es lo que roman quiere que entendamos: "separar la interfaz del acceso a datos".

Saludos

Siempre, en todos los proyectos, separo "los datos" de la "presentación", pongo en los DataModules los Querys, DataSets, etc. y en los Forms sólamente los DataSources pertinentes enlazados a los Datamodules.
Y, por supuesto, creación/destrucción dinámica de Forms, DataModules, etc
Creo que es la mejor forma de tener un orden y claridad en un proyecto.
En cuanto a la excusa de que no caben en pantalla, a mí no me parece motivo, pero bueno, cada uno tiene sus gustos y manías, y todas son respetables.