Re: Simbolos dentro de cadenas

Gunnar Wolf <gwolf(at)gwolf(dot)org> escribió: Henry dijo [Thu, Mar 15, 2007 at 07:53:30AM +0100]:
> bueno, para comenzar no me gusta usar trigger, tambien soy poco de
> usar vista, ya que cuando hay pocos datos en la BD son buenas pero
> cuando la informacion va creciendo se ponen algo lentas, se refiero a
> las vistas.

Humh... Las vistas tienden a ser muy eficientes, según lo que yo he
podido observar :) Mi recomendación va más bien porque rara vez vale
la pena la rigidez que te impone _una_ consulta prefabricada - pero si
la requieres, para algo son!

> que raro que digas que no se obtiene alguna ventajas en rendimientos
> al usar funciones, o es mejor hacer 5 select seguidos en el cliente
> para validar datos antes de un insert, update o delete (osea
> aumentar el trafico de la red, imaginate en ambiente web). Ademas de
> mencionar los planes de ejecucion para las funciones.

No, claro, si vas a hacer una secuencia de operaciones, adelante, crea
una función. Sin emabrgo, si vas a hacer algo como:

CREATE FUNCTION registra_hijo (integer, integer) AS $$
DECLARE
padre ALIAS FOR $1,
hijo ALIAS FOR $2,
BEGIN
INSERT INTO relaciones (id_padre, id_hijo) VALUES (padre, hijo);
END
$$ language 'plpgsql';

Pues... ¿qué sentido tiene? Y créeme, me he encontrado con muchos
casos como este, en que el programador cree de este modo estar
"empujando" la lógica a la BD. Creo que tendría mayor sentido, en tu
clase Cosa, tener:

sub agrega_hijo {
my ($self, $hijo) = @_;
my $sth = $self->{db}->prepare('INSERT INTO relaciones (id_padre, id_hijo) VALUES (?,?)');
$sth->execute($self->{id}, $hijo->{id});
}

por poner un ejemplo simplista, claro está ;-)

> Tambien por
> cuestiones de seguridad el poner los nombres de columnas y tablas en
> tu codigo fuente, asi como tambien el usuario no esta trabajando
> directamente con la tabla sino con las funciones lo cual hace menos
> posible algun ataque de inyección SQL y se le puede asignar
> privilegios a las funciones sin ningun problema.

Momento, momento... Acá estás confundiendo peras con gimnasia.
lo que quiero decir es que cuando usas una funcion en postgres para alguna operacion,
se pone implemente

select * from tabla where campo=parametro_1;

en cambio cuando usas algo asi en alguna app,
la mayoria de lenguaje lo usan asi:

sql="select * from tabla='" + parametro_1 + "'"; (creo que power builder no)

y ya sabemos que puede pasar, si un usuario pone un valor mal intencionado en parametro_1, al menos que primero asegures que parametro_1 es un valor adecuado para la consulta, osea tendria que crear alguna subrutina para esto, la mayoria de aplicaciones ya vienen con subrutinas para esto, algo como 'prepare' o algo asi.

como vez la funciones de postgres y otros DBMS hacen este procedimiento limpiamente, sin preocuparse de que valor se le va a asignar para realizar los filtros.

es por eso que tambien evito en lo posible usar la sentencia 'execute' de postgres, al menos que sea yo mismo quien ponga los valores para armar la consulta.

en lo que son las vista, yo estuve usandolas hasta hace poco, hasta que me di cuenta que usando funciones, devolvia los registro mas rapido, porke? no lo se,
pero mas que todo por eso lo hice y por lo ya antes explicado.

bueno, para serte sincero hasta un insert into simple, lo pongo en funciones,
y bueno no creo que traiga rigides muy alta hacerlo.

ah, una pregunta, una vista tambien no se tomaria como pre-fabricada?

---------------------------------

LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com