Depende del tipo de aplicación, los conocimientos que tengas, como se van a acceder a esos datos, la arquitectura del sistema... No hay una respuesta perfecta que valga para todo, al igual que tampoco hay una sola respuesta buena para cada problema.
Algunos ejemplos de cosas ha tener en cuenta
.- Los procedimientos almacenados permiten tenerlo todo en la BDD y el codigo fuente esta compilado contra el esquema de BDD, lo cual evita errores al modificar el esquema de la BDD. Sin embargo centraliza la carga en el servidor de BDD y es menos portable entre distintos tipos de BDD.
.- Un modelado orientado a objetos estilo ORM facilita la implementacion de la lógica y hacer uso de los estupendos IDEs de Java, además de ahorrarte escribir bastante SQL (aunque sigues escribiendo pseudo-SQL para cualquier cosa que no sea trivial). Además es más fácil de portar de una BDD a otra. Sin embargo, si el tratamiento de datos no se adapta bien al modelo clase=tabla, el rendimiento puede verse empeorado bastante y hace falta tener mecanismos para asegurarse de que la relacion ORM se mantiene correctamente cuando se cambia la BDD.
.- Un mecanismo de mantener las sentencias SQL de forma manual o semimanual es el más flexible y permite adaptarse a casi cualquier esquema de BDD y modo de proceso aprovechando al máximo el poder de SQL. Sin embargo requiere conocimientos de SQL y hay que escribir mucho código SQL parecido, además que el asegurarse de que el esquema de BDD y las sentencias SQL se mantienen sincronizadas corren a cuenta de uno mismo.
.- Si la BDD necesita poder ser accedida desde otras aplicaciones, hay que asegurarse que las caches intermedias (caso del modelo ORM) no interfieren y que se asegura la integridad referencial y las reglas de negocio se cumplen en todos los casos. Asi que si implementamos reglas de negocio en Java, por ejemplo, accediendo por SQL desde otra aplicacion habria que replicar esas reglas de negocio.
.- Segun lo que quieras hacer, un arquitectura Java 100% de arriba-abajo permite una mayor integracion y te suele da muchas facilidades, como poder usar tus objetos en la vista etc. Sin embargo te quedas atado facilmente a Java y a una tecnologia de vista dependiente, y en caso de cambiar la cosa se complica.
etc.
. No es para asustar, es simplemente para dejar claro que hay muchas circunstancias y soluciones diferentes y que lo más importante es no quedarse obsesionado con encontrar
LA solución, que no la hay.
Mi recomendación es encontrar algo que sirva para el problema que queremos solucionar y si algo nos da problemas, no quedarnos en eso por que es lo que alguien más usa o hemos leido. Al final lo habitual es acabar con un repertorio limitado de soluciones para los problemas que se suele encontrar uno, pero no hay que rasgarse las vestiduras por si nos encontramos un problema nuevo y lo que usabamos no acaba de servir. Hay que estar abierto de mente.
S!