Leyendo la impresionante (por el contenido) presentación de la arquitectura de eBay (vía Tecnorantes) he visto reflejada parte de mi filosofía de programación (que no siempre he podido seguir, por desgracia).
Uno de los puntos que más me ha gustado leer es lo de: “No stored procedures”. Es algo que siempre me ha parecido incorrecto, el poner parte de la lógica de la aplicación en la misma base de datos, lo he hecho, claro, pero nunca me ha gustado. Primero: creas una dependencia con el sistema de base de datos elegido. Segundo: cargas al servidor de base de datos con un trabajo extra, que en determinados entornos no es conveniente. Tercero: Te obliga a programar en lenguajes que en muchos casos, veáse TransactSQL, son una birria para desarrollar y no digamos para depurar (_aunque últimamente esto ha cambiado_)
Desarrollar la lógica separada de la base de datos tiene la ventaja que puedes utilizar una infraestructura n-tier, puedes manejar el repositorio de código fuente mejor, es más fácil incorporar nuevos programadores puesto que todos desarrollan en el mismo lenguaje, puedes reaprovechar código…
Una buena recomendación, en la mayoría de los casos.
Muy interesante!
Realmente espectacular el sistema.
Por otro lado, yo no me atrevería tanto como a decir que los procedimientos almacenados no deberían a usarse en la maoría de los casos. He visto BBDD Oracle donde realmente se les saca un rendimiento bestial. Desde luego que la empresa estaba “enganchada” a Oracle, pero era una decisión estratégica, y una vez tomada esa decisión hay que sacar el 110% de las herramientas.
Otra cosa que me ha llamado la atención es sobre cómo escalar el J2EE:
“Step 1.- Throw out most of J2EE”
¿esto lo entiendo bien si significa que pases de casi todo en J2EE? ¡Servlets y listo! Dura conclusión, aunque ya tenía mis sospechas sobre esto…
Esta claro que cada caso es TOTALMENTE diferente.
Básicamente entiendo que al pasar la lógica de los procedimientos almacenados a código J2EE (o .NET, o lo que sea) da una independencia del sistema gestor de bases de datos que en muchos entornos es deseable.
Por otra parte en sitios de tan elevado tráfico mejor dividir y que el SGDB se dedique a archivar y recuperar datos y otros componentes (aplicaciones, capas, servidores, etc.) a aplicar las lógicas a dichos datos.
Sobre lo que dices del J2EE, la traducción es esa, pero no puedo opinar porque nunca he trabajado con Java.
Un saludo.
Hola de nuevo!
Yo además del grupo Anti-Cursores, me haría del grupo Anti-StoredProcedures y Anti-Triggers.
Yo no se porqué, pero me creo en las palabras de Jose Alberto y seguro que ha hecho mas de uno y de dos… SP’s 
Saludos,
Ora et Labora.
A mí me hace ruido el tema de la independencia de la base de datos como objetivo: no creo que sea posible (es decir, no creo que sea posible sin cambiar el código a un costo razonable en utilización de los recursos de base y performance) y salvo que se trate de un producto enlatado, tal vez tampoco deseable ( yo preferiría tener varias versiones de DAL/DAO y desplegarla con la correspondiente a cada base )