Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] ¿Que opinan de esto?

From: Francisco Javier Morosini Eguren <francisco(dot)morosini(at)gmail(dot)com>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] ¿Que opinan de esto?
Date: 2011-11-22 00:13:21
Message-ID: CABofrE3PkCoozW7LXnh3fp8bibvT=21J3kUmHVLmhEw2+qK0Tg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Los Business Object generalmente son clases instanciadas de un manejador
ORM para facilitar la abstraccion del bajo nivel, pero no necesariamente la
logica de negocio que consulta se la da a un ORM sino que puede llamar a
los SP, eso es lo que menciono, el Business Object como punto de control
que puede usar ORM y SP. es un tema de orden, si el cuello de botella son
los discos que es lo que usa la DB, bueno, son los discos. pero la App ve
la DB, no discos. discutir sobre ello no es productivo creo asi que ganan
los discos.

y eso de las licencias y lo propietario, bueno, java es orientado a objetos
y por ello se creo el ORM. porque las DB relacionales se pueden tunear,
cosa que no ocurría con las DB orientada a objetos.

Aca el tema es que no se debe dar todo el trabajo a un ORM porque
coincidimos en que es poco inteligente, pero algunos profesores entienden
eso porque no han visto el impacto de performance en el mundo real cuando
todo es ORM.

2011/11/21 Jaime Casanova <jaime(at)2ndquadrant(dot)com>

> 2011/11/21 Alejandro Carrillo <fasterzip(at)yahoo(dot)es>:
> >
> >
> http://kartones.net/blogs/coco/archive/2009/11/27/la-capa-de-negocio-ii-aspectos-de-implementaci-243-n.aspx
> [...]
> >
> > El procedimiento almacenado anterior muestra un ejemplo de como no
> deberían
> > hacerse las cosas, en su lugar, debemos crear 3 procedimientos
> almacenados,
> > uno por cada DELETE y orquestar la transacción de borrado en la capa de
> > negocio.
>
> lo cual es obviamente incorrecto si es que un registro depende del
> otro (aunque claro te podrias ahorrar trabajo si el FK fue creado en
> la base como ON DELETE CASCADE), de lo contrario podrias dejar
> registros sueltos o le puede salir un error al usuario si el
> programador olvido llamar alguna de las funciones
>
> > Los procedimientos almacenados deberían ser una herramienta para
> persistir
> > datos, no un repositorio de lógica de negocio,
>
> esta, a todas luces erronea idea, es realmente un problema social...
> "la gente estaba forzada a usar herramientas privativas"
>
> que pasaba si tenias tu sistema en Oracle y mañana necesitabas
> replicar? tenias que comprar la licencia de replicacion y si querias
> algo mas posiblemente debias comprar alguna otra licencia... y eso
> pasaba con todas las herramientas privativas. La solucion fue agregar
> una capa de abstraccion para que la aplicacion fuera independiente a
> la base de datos y asi poder cambiarla libremente (de modo que
> pudieras comprar una con licencias mas baratas o mas rapida, etc, etc,
> etc)
>
> quienes usamos postgres no tenemos este problema porque no hay version
> comercial, algunos (como la corte de Wisconsin de USA) han decidido
> que el depender de una base de datos (postgres en este caso) no es tan
> malo y que el eliminar esa capa implementada en Java llevo a mejorar
> el rendimiento y a simplificar código (ellos tuvieron que agregar una
> caracteristica a postgres para poder hacer eso y tal parece que ha
> sido tan beneficioso que le han permitido a Kevin Gritner agregar mas
> cosas a postgres para simplificar aun mas el codigo de ellos).
>
> No, no es porque la base de datos sea el cuello de botella sino que
> para mantener el codigo independiente los ORM deben hacer solo mas
> simple o consultas mas complejas de lo necesario (por ejemplo, con
> montones de LEFT JOINs innecesarios)... ademas como *los discos* son
> el mayor cuello de botella y la base es la que accede a los discos es
> mejor dejarla hacer su trabajo en cuanto a que tabla leer primero en
> lugar de llenarla de miles consultas repetidos en bucles inutiles
>
> --
> Jaime Casanova www.2ndQuadrant.com
> Professional PostgreSQL: Soporte 24x7 y capacitación
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org
> )
> Para cambiar tu suscripción:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>

--
<inflex> really, I see PHP as like a strange amalgamation of C, Perl, Shell
<crab> inflex: you know that "amalgam" means "mixture with mercury",
more or less, right?
<crab> i.e., "deadly poison"

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Lazaro Rubén García Martinez 2011-11-22 01:35:12 RE: Configuración de Postgres en producción
Previous Message Jaime Casanova 2011-11-21 23:50:07 Re: [pgsql-es-ayuda] ¿Que opinan de esto?