Re: Duda con procedimientos almacenados.

Buenos días estimados miembros del foro. Recomiendo no leer a quienes no
les importe el tema de referencia que se escapa de postgres

Estimado Mario, opinar de esto es como si pidieras consejo sobre como
vestirte, sin saber si sos gordo o flaco, alto o bajo, joven o viejo y
peor aun a donde tenes que ir. Si fueras a una entrevista, un traje y
corbata seria un buen consejo, pero no lo sería si fueras a la tribuna a
alentar a tu equipo de futbol, y seguramente pesimo si fueras a la playa
una tarde de verano.

Dicho esto y teniendo en cuenta mi ignorancia, me arrogo contarte
algunas experiencias personales, con la esperanza de que te fuera útil.

Alla por el principio del 2000 cuando dejaba los aplicativos cliente
servidor, la moda imponia n-capas, de la mano de java, lo recomendable
era meter las reglas en la capa del medio (servidor de aplicaciones),
pues la promesa era mejor escalablidad, podias mas facil cambiar de
motor de BD, podias usar clases con mayor naturalidad, y asi los
analistas funcionales pasaban las reglas de negocio como casos de usos a
los mismos programadores java, y los DBA, ni se enteraban. Todo muy
lindo... pero en aplicaciones chicas o medianas, donde las estructuras
de desarrollo son mas pequeñas, donde no podes clasterizar el servidor
de aplicaciones, esto resulto tedioso, mucho mas trabajo, que si bien te
daba mas prolijidad, te restaba performance.

Tambien complica la seguridad, pues las reglas de negocio transforman
datos, y muchos (yo incluido) tienen mas tranquilidad si el log, y la
seguridad es responsabilidad exclusiva del motor. (Solo el motor fuera
el que permite hacer o no a un usuario algo sobre un objeto, y no
dispersar esto en varias responsabilidades)
Es otra cosa en una gran estructura que tenga un empleado dedicado al
rol de configurador, que lleve una linea base, para saber que versión es
la que se uso para hacer que con el dato, que lleve las matrices de
trasabilidad. Que tenga un DBA, Arquitecto, PM, etc. Y que tenga
artefactos instalados, que propagen los datos de contexto de la sesion,
para que cada capa sepa quien o en nombre de quien esta haciendo (Proxy
authentication)
Luego alla por el 2010 (aprox) me toco formar parte de un proyecto
grande, (Modernizacion de una provincia de Argentina) Al fin, todo esto
tan tentador estaba plenamente justificado, el fierro era un data center
como corresponde (varios millones de dolares clusterizados tanto el
motor como el servidor de aplicaciones), tenia un nutrido grupo de
profesionales para cumplir los roles. Pero luego de analizar termino
siendo un mix, ya que efectivamente pusimos las reglas de negocio
siempre que podíamos en java, pero los proceso pesados y con
periodicidad mensual, semanal o incluso diaria, (liquidación de sueldos,
etl para DW por ejemplo) en el servidor de base de datos.

Pero como comente al principio todo depende del caso en particular y de
los millones de aspectos que pueden ser determinantes, no obstante creo;
desde mi humilde opinión: lo mas simple y recomendable es justamente el
mix, y analizar regla por regla donde conviene ponerla, teniendo en
cuenta la seguridad, la usabilidad del usuario, la respuesta del
aplicativo en cuanto a tiempos, la reusabilidad del modulo, etc.

En contra posición las posturas dogmáticas de poner todo en un lado o en
el otro, no las miro con gracia, pensando así, los defensores de poner
todo en la capa del medio por ejemplo .. no dejarian en la base ninguna
constraint, ya que podrian ser consideradas reglas de negocio (y vi
soluciones asi que en la base ni las FK estaban) y bue sobre gustos.....

De mis épocas de delphi añoro Midas, que propagaba (o intentaba por lo
menos) las reglas de negocio del servidor al cliente por todas las
capas, para convinar las ventajas de unas con las de la otra, una muy
buena idea pero no se en que quedo, supongo que murio aplastada por la
complejida.

Nuevamente pido disculpas al resto de los miembros del foro, por lo extenso.

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda