Re: Simbolos dentro de cadenas

Gunnar Wolf <gwolf(at)gwolf(dot)org> escribió:Ahora, Gabriel... Si alguien te vendió que _todas_ las consultas que
requieren parametrización deben estar almacenadas en la BD, lo siento,
te vendieron un argumento enredoso e inmantenible. Es muy fácil abusar
de las funciones en BD, y es muy doloroso mantener código en varios
lenguajes simultáneos. Puedo hablarte por experiencia: Hice hace años
un proyecto con varias decenas de funciones y otras varias decenas de
triggers, con el manejo de una gran cantidad de lógica clavada en la
BD. La rigidez me mató. Y claro, hoy no dejo de usar funciones, vistas
y triggers donde hacen falta - pero abusar de ellos es la muerte. ¡Ah,
claro! no obtienes ninguna ventaja de rendimiento - muy al contrario,
ejecutar repetidamente procedimientos almacenados puede matar tu
rendimiento. En Postgres y en otros motores.
que tal Gunnar,
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.

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. 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. Tampoco hay que preocuparse por los caracteres especiales ya sea '\ @ä$:¨^ al hacer un update,delete o insert. 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.
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.

pero obviamente como lo mencionastes, usar funciones tambien tiene sus desventajas ya que no es un lenguaje estandar SQL, po lo tanto puede haber problemas de portabilidad.Otra es que algun cambio en los parametros de las funciones tengas que ir al codigo fuente a hacer algun ajustes.

En mi caso, una vez hecho mi app, ya casi ni lo toco, simplemente hago algunas modificaciones en las funciones, obviamente solo en caso de aumento de parametros de las funciones es necesario ajustar tambien mi codigo fuente.

Para no enredarse con las funciones y demas , es necesaria una buena documentacion de la BD como del app.

Sobre porque uso 'select ' para retornar 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) .

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

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