Re: Re: [pgsql-es-ayuda] Re: Funciones con argumentos vacíos

From: jsgarcia(at)seguridad(dot)unam(dot)mx
To: Jose Vasquez <cibercol(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Marcos Ortiz Valmaseda <mlortiz(at)estudiantes(dot)uci(dot)cu>, PosgreSQL <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Re: [pgsql-es-ayuda] Re: Funciones con argumentos vacíos
Date: 2009-06-04 00:39:24
Message-ID: 20090603193924.raop2ro50kwwoccs@correo.seguridad.unam.mx
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Esa puede ser una buena razón para usarse las funciones. En nuestro
caso sólo se trabaja con PHP y como ya lo había comentado en otro
correo, aqui se argumenta que se hace por evitar SQL Injection. Aunque
ya ha dicho Álvaro que eso no evita ese tipo de ataques. Nosotros
utilizamos el Zend Framework y es mucho más fácil hacer uso de éste,
pero me dicen que no se deber de ver ningún tipo de consulta a nivel
código.

Creo que la conclusión sería que todo va de acuerdo a las necesidades
y en ocasiones a las órdenes.
_________________________________________________________________________

Jose Vasquez <cibercol(at)gmail(dot)com> ha escrito:

> En nuestra empresa se exige que aunque sea para una cosa muy sencilla se
> haga una función, por dos razones:
>
> Inicialmente si no se han definido las tablas y los procesos, etc, etc, se
> puede hacer una funcion que devuelva valores sin necesidad de que existan
> datos y se hayan hecho los respectivos análisis de modelamiento.
>
> Entonces simplemente se consideran los parametros de entrada, asi como de
> salida de la función y se hace un esqueleto.
>
> De esta forma la aplicación cliente se puede adelantar, bien sea en C++ o en
> GWT o en PHP, o en Rails o en Django y no hay retrazo en la programación.
>
> Finalmente cuando se hayan realizado las respectivas tablas y demas y las
> tablas contengan datos, entonces se cambia la función por la real, pero la
> programación en el lado del cliente no se modifica en nada, esto es sigue
> llamando la misma funcion con los mismos parametros.
>
> También consideramos importante que si ya no es un simple insert o una
> simple consulta lo que se requiere hacer, sino que se complica y requiere
> consultas muy complejas o toma de decisisiones, la funcion permite esta
> flexibilidad y pues simplemente se realizan los cambios respectivos.
>
> Hemos anotado esto dentro de las buenas practicas de programación.
>
> Otro beneficio adicional es que hemos realizado algunos objetos en JAVA que
> consultan directamente en las tablas del sistema "aquellas que empiezan con
> pg_..." para ver los parametros de cualesquier funcion y dinamicamente armar
> los formularios con GWT. Antes lo haciamos en php, pero hemos visto
> bastantes mejoras en dinamismo con GWT.
>
> Ustedes que opinan.
>
> José VASQUEZ
>
> 2009/6/3 Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
>
>> Marcos Ortiz Valmaseda escribió:
>> > Verdaderamente es más fácil en PHP (relativamente), pero no le estarías
>> sacando provecho a la programación de funciones dentro del gestor, lo cual
>> muchos usuarios y desarrolladores recomiendan.
>> > La intencion sería trasladar toda la lógica de negocio al gestor y la
>> capa de presentación desarrollar por ejemplo en PHP con algún framework de
>> los existentes (Symfony(es que el uso ahora),CodeIgniter,CakePHP,etc)
>>
>> Ya, pero un INSERT no califica como "lógica del negocio", ¿o si? Las
>> operaciones complicadas tiene sentido encapsularlas en una función, pero
>> una cosa tan trivial como la que se planteó originalmente no tiene mucho
>> propósito.
>>
>> --
>> Alvaro Herrera
>> http://www.flickr.com/photos/alvherre/
>> "La Primavera ha venido. Nadie sabe como ha sido" (A. Machado)
>> --
>> TIP 7: no olvides aumentar la configuración del "free space map"
>>
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Attachment Content-Type Size
Clave PGP =?iso-8859-1?b?cPpibGljYQ==?= application/pgp-keys 1.7 KB

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Daniel Hernández 2009-06-04 01:23:25 Re: agrupando y tomando el primero de cada grupo
Previous Message Daniel Hernández 2009-06-04 00:32:02 Re: Prehistoria de PostgreSql en Chile (off topic)