Foros Club Delphi

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)
-   Debates (https://www.clubdelphi.com/foros/forumdisplay.php?f=29)
-   -   Firebird Procedures VS Delphi Procedures (https://www.clubdelphi.com/foros/showthread.php?t=85926)

ASAPLTDA 26-05-2014 05:33:29

Firebird Procedures VS Delphi Procedures
 
Hola Todos
Quisera tener sus comentarios si uno debe ejecutar validaciones y procesos usando delphi o usar los procedimientos en la base de datos para ejecutar procesos y validaciones, que es mas rapido, veo que las bases de datos tienen su propio lenguaje para ejectuar estos procesos pl / sql etc
Saludos
uso firebird 2.1 , delphi 5/x2

Neftali [Germán.Estévez] 26-05-2014 09:39:03

Siempre será más rápido ejecutarla en el Servidor de Base de Datos, pero tal vez no siempre aconsejable.
A mi personalmente me gusta hacer las validaciones (a priori todas) en el programa. Son más fáciles de controlar, de "debuggar", el código está centralizado, más fácil para detectar errores, mejor para versionado,...

En operaciones normales (no especiales) sacrifico la velocidad en pro de otras cosas como las que te he comentado.

Eso sí, para procesos críticos, importantes o que requieren velocidad de proceso, deben ir en el SGDB, pero intento que sean los mínimos.

Supongo que habrá quien no esté de acuerdo, pero yo lo hago así.

He visto Base de Datos con cientos de procedimientos y triggers (casi para cualquier cosa), y eran una verdadera locura en varias situaciones:
* A la hora de migrar a otro sistema.
* A la hora de actualizar determinados objetos de la base de datos por las dependencias.
* A la hora de grabar de buscar un simple error de porqué un dato no se guardaba correctamente. Busca en el código, busca en los Stored, y busca en los triggers... :(:(

newtron 26-05-2014 10:07:44

Hola.

Como bien apunta el amigo Neftali es bastante más fácil de mantener el código si está dentro del programa que no en procedimientos almacenados o triggers. Yo particularmente no uso los procedimientos almacenados pero si los triggers para asegurarme de que SIEMPRE que se añada, edite o anulen registros sea desde donde sea se efectúen ciertas operaciones para mantenimiento de xistencias, acumulados, etc.

Saludos

Combat-F2D 26-05-2014 10:15:17

yo preferentemente uso las validaciones en la Base de Datos, o todas las que puedo y son razonables
asi si hay alguna inconsistencia, esta se encarga de lanzar la excepcion, evita actualizaciones en los
clientes en un momento dado.

trabajar en el codigo de la aplicacion pienso que da mas versatilidad, mas posibilidades.

creo que ambas cosas aplicadas en su mejor medida puede ser lo mas aconsejable

ecfisa 26-05-2014 17:44:04

Hola.

Coincido con lo dicho.

En líneas generales uso los sp:
. Para disminuir el tráfico de red y aumentar la seguridad.
. En consultas complejas o aquellas en que alguna depende del resultado de otras.
. Para operaciones que implican actualizaciones o cargas masivas.

Realizo casi la totalidad de validaciones desde la bd (a nivel campo, integridad referencial, etc). El resto (consultas, calculos, etc) desde el lenguaje.

Saludos :)

ASAPLTDA 27-05-2014 05:11:22

El poder de las bases de datos
 
Hola a Todos, He leido sus comentarios y me parecen que son aporte valioso a mi proyecto de migrar firebird a PostgreSql, ya que leyendo las caracteristicas de esta base de datos su PL/SQL es muy poderoso , por supuesto sigo estudiando y leyendo sus comentarios.
Mi esperiencia con firebird ha sido excelente, pero vengo de sistemas as400 donde hay una marcada tendencia en usar los proceimientos de la base de datos sin importar que lenguaje se utilice, para evitar el trafico de la red.
Firebird tiene algunos detalles molestos en el campo d integridad de datos y su carencia de funciones , el manejo de %row para mover los campos a las variables, por eso me encanta oir sus comentarios de donde debe estar los procedimientos

MAXIUM 27-05-2014 08:14:02

¿Es hoy un problema el ahorrar lineas de código en favor de los recursos de memoria tanto en disco como en RAM?

¿Es hoy un problema el trafico de red?

Combat-F2D 27-05-2014 08:44:18

Cita:

Empezado por MAXIUM (Mensaje 476869)
¿Es hoy un problema el trafico de red?

creo que eso te lo tienes que responder tu mismo

Casimiro Notevi 27-05-2014 10:21:53

Cita:

Empezado por ASAPLTDA (Mensaje 476867)
Firebird tiene algunos detalles molestos en el campo d integridad de datos y su carencia de funciones , el manejo de %row para mover los campos a las variables, por eso me encanta oir sus comentarios de donde debe estar los procedimientos

No entiendo, ¿puedes explicarlo con un poco más de detalle?

ASAPLTDA 27-05-2014 14:05:04

Alguno detalles Molestos
 
Cita:

Empezado por Casimiro Notevi (Mensaje 476874)
No entiendo, ¿puedes explicarlo con un poco más de detalle?

1.En el transcurso he notado que en caso de agregar alguna restricción posterior a los registros , los datos existentes no son validado previo a adicionar la transaccion en la base de datos

2. en un cambio de campos float a decimal (18,10) genero inconvenientes cuando efectuaba un multiplicación con otro campo decimal

3. Cuando se ejecuta el restore de un backup informa de errores que uno desconocía por ejemplo ha sucedido que informa que claves primarias no tienen la restricción not null, los cambios los efectuó usando ibexpert gratuito

Por otro lado quiero decir que la base la he usado sin ningun problema de perdida de datos, es muy facil de manejarla, instalarla es una excelente herramienta de trabajo.

Tal como comente he estado leyendo postgresql y tiene muy buenas herramientas y me ha gustado , pero debo leer y investigar mas para efectuar un cambio. Otra parte que me parece intersante es que no se requiere colocar el cliente de la base de datos en los pc*clientes o en telefono androit usando los componentes pgdac(devart)

Casimiro Notevi 27-05-2014 21:04:17

Bueno, esas incidencias no son culpa de la BD en sí.

De todas formas, postgresql es una muy buena base de datos también (y libre), y depende para lo que vayas usarla, puede ser más indicada.
En cuanto a que no necesitas instalar un cliente, bueno, siempre hace falta, si no lo haces tú es porque los componentes lo hacen por ti, al llevarlos integrados.

ASAPLTDA 28-05-2014 02:32:02

Instalacion Cliente Postgress liqpq.dll
 
Cita:

Empezado por Casimiro Notevi (Mensaje 476895)
tú es porque los componentes lo hacen por ti, al llevarlos integrados.

Casimiro, en su experiencia sabe donde colocar el cliente de postgress libpq.dll (folder uso windows x7 64b) estoy usando los componentes sqldirect, alguna vez hice una prueba de conexion y si funcionaron (creo que era version 8.x) pero ahora con la nueva version no encuentra la DLL y retrona ese mensaje y busca otra dll vsnit.dll ^\||/

Casimiro Notevi 28-05-2014 09:44:09

La verdad es que no tengo ni idea, yo dejo los directorios predeterminados al instalar cualquier cosa.

ASAPLTDA 28-05-2014 13:27:29

postgressql + sqldirect Falta Libpq.dll + vsnit.dll
 
Cita:

Empezado por ASAPLTDA (Mensaje 476906)
Casimiro, en su experiencia sabe donde colocar el cliente de postgress libpq.dll (folder uso windows x7 64b) estoy usando los componentes sqldirect, alguna vez hice una prueba de conexion y si funcionaron (creo que era version 8.x) pero ahora con la nueva version no encuentra la DLL y retorna ese mensaje y busca otra dll vsnit.dll ^\||/

Hola adicione la ruta de postgresql al path del sistema y arregle el problema gracias por su aporte

C:\Program Files (x86)\PostgreSQL\9.3\bin

Casimiro Notevi 28-05-2014 16:50:42

Ya he visto el otro hilo. Por cierto, ¿por qué me hablas de usted? :D

newtron 28-05-2014 17:50:52

Cita:

Empezado por Casimiro Notevi (Mensaje 476926)
Ya he visto el otro hilo. Por cierto, ¿por qué me hablas de usted? :D

Porque eres un tío importante, además de mayor. :p

Combat-F2D 28-05-2014 20:29:35

Cita:

Empezado por newtron (Mensaje 476933)
Porque eres un tío importante, además de mayor. :p

vamos a ver, te equivocas, el avatar es de Rompetechos, noooo del ABUELO CEBOLLEEEETA....
es broma claro.. eso si, es un tio importante

Casimiro Notevi 28-05-2014 23:09:34

Mayor sí que soy, toda la vida he sido mayor porque nací mayor, nunca he sido joven :rolleyes:
Importante, no, eso sí que no :D


La franja horaria es GMT +2. Ahora son las 11:54:36.

Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi