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!
>
No voy a debatir sobre esto, tengo opiniones
encontradas en uno u otro punto con Henry y en uno u
otro punto con Gunnar.
Lo dejo para otro momento, quiza para alguna charla de
boliche en alguna convencion, quiza en el dia de
PostgresSOL, no quita que en algun momento, me tienete
y conteste algo.
Lo que quiero felicitar a Henry y a Gunnar es por la
forma en que exponen las ideas en este debate.
Cada uno con sus fundamentos, pero sin denostar la
opinion del otro, los felicito a los dos, ojala esto
se torne cotidiano en el foro.
> > 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. Para
> evitar inyección de SQL, lo que debes hacer es
> evitar meter cualquier
> elemento proporcionado por el usuario a tus cadenas
> SQL - ¿cómo?
> Preparando las órdenes antes de ejecutarlas (puedes
> verlo en la
> función que hice). En realidad, tener una aplicación
> completa que no
> maneje SQL en lo más mínimo, es demasiado pedir...
> Es casi casi como
> programar una aplicación que no conozca la
> estructura de los datos que
> maneja. Ni siquiera con frameworks (p.ej. Rails) que
> hacen lo posible
> por evitarte escribir el SQL directamente - los
> nombres de las
> tablas y columnas siempre son fundamentales para tu
> código. Puedes,
> sí, mantener diferentes órdenes ejecutadas por
> diferentes usuarios, o
> cosas por el estilo.
>
> > Tampoco hay que
> > preocuparse por los caracteres especiales ya sea
> '\ @ä$:¨^ al hacer
> > un update,delete o insert.
>
> Nuevamente: Prepara una cadena SQL sin elementos
> externos. Ejecuta con
> los datos proporcionados por el usuario. No hay
> posibilidad de
> inyección de SQL.
>
> > El uso de manejo de transacciones,
> > donde mi lema es 'O se hace todo lo necesario o
> nada se hace' es
> > obvio que por motivos de integridad de datos.
>
> Completamente de acuerdo en esto - No lo incluí en
> la funcioncita de
> arriba para mantenerla sencilla, pero sí, cualquier
> cosa que ocupe más
> de una operación a la BD debe ir en una transacción
>
> > Que la logica del negocio se encuentre
> > centralizada asi que no solamente puede ser
> utilizada por una
> > aplicacion sino por varias otras que la necesiten.
>
>
> Acá... A veces y a veces. Depende de cada caso. Por
> ejemplo, en mi
> caso, yo uso la BD principalmente como un depósito
> de datos
> estructurados (y con algunos triggers mantengo
> pedacitos de esa
> estructura que no son representables fácilmente en
> el DDL). Hago una
> capa back-end en mi lenguaje de preferencia, que
> representa lo que les
> ha dado por llamar la «lógica del negocio» (¡Dios me
> libre de hacer
> negocios! ;-) ), y hago otra capa que se encarga de
> la interacción con
> el usuario. O, cuando escribo con Ruby, me ciño al
> tradicional patrón
> MVC, usando a la BD estrictamente como la mitad de
> abajo del modelo.
>
Aca si me tente, que facil de seducir soy, lo voy
hacer en forma de pregunta no de afirmacion.

"Empujar las reglas de negocio", tratando de que
cualquier app, se sirva de las funciones, esta mal?

Aunque soy partidario de "empujar la regla" admito que
el a veces y a veces, es una buena contestacion, por
el hecho de que a veces armas una aplicacion, por
ejemplo para la web, con cosas por ejemplo que si bien
estan contempladas en el MER, no se contemplaron en la
necesidad "comercial" del momento, puesto que la
operativa del "negocio" cambio, determinando nuevas
funcionalidades, todos sabemos que las funciones son
mas peregnes y cambiantes en el tiempo, que los
modelos de datos.

Entonces en este punto el a veces y el a veces resulta
bueno en cuanto a las funciones, pero igual trato de
empujar la mayor parte de las mismas hacia la BD, por
que todavia no veo lo malo.

En cuanto a las vistas defiendo el tenerlas en la BD.
por que para algo tenemos el explain analyze, aunque
en PostgreSQL yo tendria que tirar esto a Jaime o a
Alvaro, para que me expliquen mejor los resultados que
tengo puesto que me falta estudio, pero normalmente si
algo en la vista es lento, trabajo en cambiar el
planteo, haciendo que todo los modulos de mi app o mis
app que la utilizen se beneficien de la optimizacion.

> ha dado por llamar la «lógica del negocio» (¡Dios me
> libre de hacer
> negocios! ;-) ),

Admito que cuando escribiste esto me desubicaste y me
obligaste a poner todo lo referido a negocio entre
comillas.
No por que no comparta tu frase, si no por que me di
cuenta que tengo que cambiar en mis discursos esta
forma de expresion y no se como hacer esto que se me
hizo costumbre.
Por que cambiarla, por que la mitad de mi programacion
va destinada a obras sociales, cooperativas de
vivienda etc. y la frase "logica del negocio" o los
insulta por decirles que lo que hacen es un negocio, o
los insulta por decirles que como no es un negocio no
tiene logica. Punto que reflexione mientras leia.

> > Sobre porque uso 'select ' para retoirnar datos
> desde una funcion, es
> > por ke no uso vistas, como dije anteriormente al
> comienzo son buenas
> > pero cuando la informacion crece se ponen un poco
> lentas (eso sucede
> > en cualquier DBMS).Y claro a veces debo hacer una
> consulta previa a
> > la principal. (trafico de red) .
>
> Vistas bien definidas, con índices bien definidos,
> no deben darte
> mayor problema de rendimiento. Al menos, no un
> problema mayor que
> hacer esa misma consulta desde la aplicacíon ;-)
>
> Saludos,
Como vieron en mi argumento anterior comparto esto de
definir y buscar optimizar siempre las vistas, ademas
de obtener el apoyo de las reglas de insert, update y
delete, para todos los usos posteriores.

Encantado de haber leido un texto tan ameno en el
foro, saluda a ustedes,
Atte.
Gabriel Colina

> --
> Gunnar Wolf - gwolf(at)gwolf(dot)org - (+52-55)5623-0154 /
> 1451-2244
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E
> F35A 8BB5 27AF
>
> ---------------------------(fin del
> mensaje)---------------------------
> TIP 6: ¿Has buscado en los archivos de nuestra lista
> de correo?
>
>
> http://archives.postgresql.org/pgsql-es-ayuda
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/