2011/11/21 Alejandro Carrillo <faster...@yahoo.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@postgresql.org) Para cambiar tu suscripción: http://www.postgresql.org/mailpref/pgsql-es-ayuda
