FireBird + Delphi 7

[[AzidRain]]

Para el amigo mcs, tienes razón es más sencillo, intuitivo y legible atacar las tablas tal como tu lo mencionas, al final cuando haces por ejemplo:

Código Delphi [-]
tabla.open;
tabla.append;
tabla.fieldbyName('micampo').AsString := 'valor';
tabla.post;

El componente que usas en realidad convierte todo eso en un insert (aunque tú no lo veas), lo mismo sucede cuando haces tabla.edit; el componente hará un "update table".

En ambos casos no hay ninguna ventaja apreciable en velocidad haciéndolo mediante la forma que mencionas o la que dice caral. Eso sí, hay que cuidarse de nunca de los nuncas hacer un "select * from tabla" sin ponernle un filtro para editar un solo registro pues entonce sí que tendras problemas de lentitud, pues te traeras todo de un jalón.

La gran ventaja de hacerlo como dices es que no tienes que revolver SQL directamente con tu código, lo que lo hace más legible.

Yo utilizo ese esquema para hacer CRUD (que es lo que más ocupa uno en entornos administrativos) y me ha funcionado sin ningún problema. También uso el esquema de caral cuando se trata de procesos tipo batch que no son interactivos.

Al final de cuentas cualquiera de los 2 métodos es correcto siempre y cuando estén bien aplicados y soportados, cualquiera va a ser lento si se basa en un mál concepto o diseño.

[[Caral]]

Hola
A mi escaso entender:
Esto:

Código Delphi [-]
tabla.open;
.............

Es exactamente lo mismo que esto:

Código Delphi [-]
Select * from Tabla

En otras palabras, te traes todo el contenido de la tabla, te guste o no.
Por lo tanto; Es mas simple, SI?, tal vez, pero no es mejor que hacer el edit, insert, ect directamente al campo sin traer nada extra.

Repito: a Mi pequeño, muy pequeño entender.
Saludos

[[movorack]]

Empezado por Caral

Hola
A mi escaso entender:
Esto:

Código Delphi [-]
tabla.open;
.............

Es exactamente lo mismo que esto:

Código Delphi [-]
Select * from Tabla

En otras palabras, te traes todo el contenido de la tabla, te guste o no.
Por lo tanto; Es mas simple, SI?, tal vez, pero no es mejor que hacer el edit, insert, ect directamente al campo sin traer nada extra.

Repito: a Mi pequeño, muy pequeño entender.
Saludos

Casi nunca uso el TTable o sus decendientes... por lo general uso un query para evitar traerme todos los registros.

Código SQL [-]
select * from tabla where id = :id

y luego hago las modificaciones en ese registro...

Código Delphi [-]
  Query1.edit;
  ...
  Query1.post;

igual trabaja para las inserciones.

Otra opinión no sobra...

[Casimiro Noteví]

Empezado por movorack

select * from tabla where id = :id
y luego hago las modificaciones en ese registro...

Es lo más sensato.

[[Caral]]

Hola
Bueno, como diria mi amigo Egostar: Depende, depende....
Si hablamos de los componentes (y por eso mencione que SI depende de ellos) en el caso de los IBQuery esto no se puede hacer, envia un hermoso error ya que no permiten hacer ediciones, inserciones etc....
Para esto se usarian los IBDataset, que en tal caso lo hacen algo diferente.
Por otro lado:
Me extraña que un programador con la esperiencia de AzidRain diga abiertamente que es lo mismo y que no afecta en la velocidad traer todos los registros con un Table.Open para hacer un edit, inser u otro y que ademas es mas simple.
No se, pero la idea es darle a las personas la solucion optima, la mas apropiada y no la mas simple que dara problemas a la larga.
Saludos

[[Delphius]]

Ya que se admiten consejos, si me lo permiten... aquí va otro:
Jamás de los jamases se debe emplear asterisco. ¡Es una práctica tediosa e ineficiente! Es algo que hay que erradicar... ¡DI NO a *!

El uso del asterisco obliga al motor realizar dos consultas previas sobre las tablas del sistema: la primera para extraer los campos de dicha tabla, la segunda para pre armar la consulta definitiva. Luego recién se lanza la consulta que se ha elaborado.

Es mucho más liviano y práctico indicar los campos EXTRICTAMENTE NECESARIOS que lanzar un select *. Si admito que es muy molesto e incómodo cuando la tabla tiene demasiados campos, pero en definitiva lo que habría que preguntarse es: ¿Es necesario suministrar todos los campos? Si es un si pues ni modo, a enlistarlos. Si la funcionalidad a la que estamos por brindar soporte no requiere devolver todos los campos... ¿Qué sentido tiene el *?

Otra posibilidad que cabría poner en discusión cuando la cantidad de campos es alta es la de preguntarse si estará bien normalizada. Encontrar un adecuado equilibrio entre la normalización y desnormalización es tanto un arte como una ciencia.



Saludos,

[Casimiro Noteví]

El uso de tablas sólo puede ser factible usarlo con las que tienen pocos registros, por ejemplo:
tbTiposIVA que va a tener menos de 5 registros.

[[Delphius]]

Empezado por Casimiro Notevi

El uso de tablas sólo puede factible usarlo con las que tienen pocos registros, por ejemplo:
tbTiposIVA que va a tener menos de 5 registros.

¿ 5 tipos de IVA? Allá... porque por este lado de la tierra los políticos se inventan uno por día. Son capaces de hasta sacar impuesto hasta por el O2 que consumimos... y para hacerlo más chungo... los cálculos del impuesto estarán basados en O2/hora.

Saludos,

[mcs]

Empezado por AzidRain

Para el amigo mcs, tienes razón es más sencillo, intuitivo y legible atacar las tablas tal como tu lo mencionas, al final cuando haces por ejemplo:

Código Delphi [-]
tabla.open;
tabla.append;
tabla.fieldbyName('micampo').AsString := 'valor';
tabla.post;





El componente que usas en realidad convierte todo eso en un insert (aunque tú no lo veas), lo mismo sucede cuando haces tabla.edit; el componente hará un "update table".

En ambos casos no hay ninguna ventaja apreciable en velocidad haciéndolo mediante la forma que mencionas o la que dice caral. Eso sí, hay que cuidarse de nunca de los nuncas hacer un "select * from tabla" sin ponernle un filtro para editar un solo registro pues entonce sí que tendras problemas de lentitud, pues te traeras todo de un jalón.

La gran ventaja de hacerlo como dices es que no tienes que revolver SQL directamente con tu código, lo que lo hace más legible.

Yo utilizo ese esquema para hacer CRUD (que es lo que más ocupa uno en entornos administrativos) y me ha funcionado sin ningún problema. También uso el esquema de caral cuando se trata de procesos tipo batch que no son interactivos.

Al final de cuentas cualquiera de los 2 métodos es correcto siempre y cuando estén bien aplicados y soportados, cualquiera va a ser lento si se basa en un mál concepto o diseño.

Esto es lo que me refería!

Por otra parte, diría que en las IBDAC un table.open no equivale a un SELECT * FROM loquesea;. Lo tendría que mirar con detalle (las IBDAC traen un monitor para ver exactamente que comandos SQL se ejecutan)...

[[egostar]]

Empezado por mcs

Esto es lo que me refería!

Por otra parte, diría que en las IBDAC un table.open no equivale a un SELECT * FROM loquesea;. Lo tendría que mirar con detalle (las IBDAC traen un monitor para ver exactamente que comandos SQL se ejecutan)...

Perdón, pero un Table.Open de cualquier componente, traé SI ó SI todos los campos de la tabla es decir

Código SQL [-]
SELECT * FROM tabla

, puedes limitar el número de registros a través de un filtro. Eso es lo que Caral está comentando desde un inicio, con el Query puedes seleccionar los campos que realmente necesitas ahorrando tiempo y recursos.

Saludos

[Casimiro Noteví]

Empezado por egostar

Perdón, pero un Table.Open de cualquier componente, traé SI ó SI todos los campos de la tabla es decir Código SQL [-]SELECT * FROM tabla

, puedes limitar el número de registros a través de un filtro. Eso es lo que Caral está comentando desde un inicio, con el Query puedes seleccionar los campos que realmente necesitas ahorrando tiempo y recursos.

Saludos

Más claro no se puede decir

El sistema de tablas está bien cuando son relativamente pocos registros, pero según vayan aumentando cada vez será más lento abrir la pantalla donde está esa tabla y cada vez tardará más en insertar un registro. Ni que decir tiene que si hay muchísimos registros en la tabla entonces ya ni siquiera será operativo y se tendrá que hacer el cambio y olvidar el uso de ttable.

El uso de ttable es el típico de los mensajes "mi programa iba muy bien pero últimamente tarda mucho en acceder y en grabar los datos, formateé el disco y reinstalé el windows, pero sigue igual de lento, cada vez más, ¿será un fallo del firebird?"

[Casimiro Noteví]

Para muestra un botón, el siguiente código corresponde a la propiedad tablename del componente tztable de los componentes zeoslib:

Código Delphi [-]
procedure TZAbstractTable.SetTableName(const Value: string); 
begin 
  if FTableName <> Value then 
  begin 
    FTableName := Value; 
    if Value <> '' then 
      SQL.Text := Format('SELECT * FROM %s', [FTableName]) 
    else SQL.Text := ''; 
  end; 
end;

[[Caral]]

Hola
Por eso digo, no hay que ser un maestro para saber algo tan básico.
Seguir insistiendo en que un table.open es eficiente o que es lo mismo que hacerlo por SQL, es perder el tiempo.
Me sigue extrañando que AzidRain defienda lo indefendible y que ademas mcs insista en esto sin conocimiento alguno, notable.
Soy novato, pero hay mas principiantes.
Saludos

[Casimiro Noteví]

Por eso las originales FreeIB Components no traían componente TTable, porque querían primar la velocidad y eficiencia. Después, las siguientes herencias creadas a partir de las FreeIB que han querido seguir siendo eficientes tampoco han traído ese componente, como FIBL, FIBplus, etc.
Sin embargo, Borland sí añadió una TIBTable en las IBX, heredadas, como todos sabemos, de FreeIB, seguramente por hacerlo más cómodo a los que venían de usar paradox o access.

Empezado por IBX

SQL := TStringList.Create;
SQL.Text := 'select ' + {do not localize}
QuoteIdentifier(DataBase.SQLDialect, FTableName) + '.*, ' {do not localize}
+ 'RDB$DB_KEY as IBX_INTERNAL_DBKEY from ' {do not localize}
+ QuoteIdentifier(DataBase.SQLDialect, FTableName);
if Filtered and (Filter <> '') then
begin
SQL.Text := SQL.Text + ' where ' + Filter; {do not localize}
bWhereClausePresent := True;

Que como se puede observar también usa, obviamente, un " select * ".
Luego, los MDO (Mercury Database Objects), que no heredaron de FreeIB, sino que decidieron heredar de IBX, también lleva un TTable, que el código parece el mismo de las IBX:

Empezado por MDO

SQL := TStringList.Create;
SQL.Text := 'select ' + {do not localize}
QuoteIdentifier(DataBase.SQLDialect, FTableName) + '.*, ' {do not localize}
+ 'RDB$DB_KEY as IBX_INTERNAL_DBKEY from ' {do not localize}
+ QuoteIdentifier(DataBase.SQLDialect, FTableName);
if Filtered and (Filter <> '') then
begin
SQL.Text := SQL.Text + ' where ' + Filter; {do not localize}
bWhereClausePresent := True;

Bueno, no parece, es que es el mismo código

Y ya no sigo con esto, creo que está claro el tema.