Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

Prodimientos almacenados (llevar todo ahi?)

23/10/2007 - 09:36 por Pablo Roca | Informe spam
Ayuda Hacer una pregunta
Hola,

Bueno estuve viendo como funcionan los procedimientos y la verdad que
resultan muy interesantes.

En una aplicacion de gestion tipica ...

Hasta uno donde debe utilizar procedimientos almacenados? Es decir ..
¿llevamos la mayor parte de nuestro codigo para ahi? solo las partes mas
criticas de una aplicación? .. Solo las consultas mas complejas ... todo?

¿Donde está el limite?


PD: Me importa muy poco que me vean mi codigo de los procedimientos
almacenados, es para aplicaciones internas.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
email Siga el debateRespuesta 101 respuestasRespuesta Tengo una respuesta

Preguntas similare

Mostrar todos los temas similares

Leer las respuestas

#41 Alfredo Novoa
23/10/2007 - 19:10 | Informe spam
On Tue, 23 Oct 2007 17:29:47 +0200, "Eladio Rincón"
wrote:

Hola Eladio

uff, me gustaría responder a este mensaje, pero no entiendo qué quieres
decir con:

los desarrolladores del primer párrafo.





A esto:

Los desarrolladores darán razones para incluirlas fuera del servidor? mm,
estoy por pensar que esos desarrolladores saben de su herramienta de
desarrollo y poco sobre la base de datos, entonces se llevan esa parte al
terreno que dominan :))





Estoy harto de verlo.

Muchos desarrolladores que he conocido solo saben lo más básico de
ANSI-SQL y no tienen ni idea de T-SQL y por eso lo implementan todo
sistemáticamente en la aplicación.


Saludos
Alfredo
Respuesta Responder a este mensaje
#42 Pablo Roca
23/10/2007 - 19:33 | Informe spam
Si hay más cosas pues te creas más métodos, pero toda la gestión de
datos la puedes hacer con un único método que tenga como parámetro una
cadena SQL. Y con eso te quitas un gran peso de encima.



Sigo pensando que queda mas ordenado poniendo buena parte de la logica en
esa capa del lado del servidor.

Yo igual. De esa forma toda la lógica estaría en el servidor.

Lo que digo es algo como hacer un proveedor ADO.NET que funcione a
través de tu Web Service, así no te enterarías si estás usando Web
Services, una conexión de red local, o cualquier otra cosa.



Ya, pero entonces utilizarías el servidor solo como un medio para acceder a
los datos, nada mas. Con eso te llevas la lógica de ciertas partes de la
aplicación al WinForm es decir .. a la aplicación en el lado del cliente.

Tampoco accederias a los procedimientos almacenados. No sé no me convence.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#43 Salvador Ramos
23/10/2007 - 20:14 | Informe spam
jeje, dile que más vale "invertir un poco" de tiempo ahora, que "perder
mucho" tiempo luego por malas decisiones iniciales :-)

Un saludo
Salvador Ramos

www.helpdna.net (información sobre SQL Server y Microsoft .Net)
www.helpdna.net/acerca_de_salvador_ramos.htm


"Pablo Roca" escribió en el mensaje
news:
Cierto que me temia una respuesta de este estilo. :)))

La leche .. cuanto me haces estudiar .. y mi jefe dice que no podemos
perder el tiempo en estudiar tanto .. jajaja

Venga .. lo miro y seguimos .. gracias!!


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Respuesta Responder a este mensaje
#44 Pablo Roca
23/10/2007 - 20:28 | Informe spam
jeje ... eso no entra en sus parámetros. Ya me dice que uno de sus defectos
es que no tiene paciencia .. mmm

Pero bueno .. es un lucha que llevo con él mucho tiempo. :)))


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#45 Salvador Ramos
23/10/2007 - 20:31 | Informe spam
No lo entiendo T-SQL está mucho mejor preparado para implementar
lógica de negocio compleja que los lenguajes de programación de
aplicaciones.

La regla general es implementar TODA la lógica de negocio en el SGBD,
excepto en los casos en los que no sea posible debido a las
limitaciones del SGBD particular que estés usando.



En esto no estoy de acuerdo, como dije anteriormente hay que estudiar qué
parte de la lógica de negocio interesa dejar en el servidor y que parte
fuera de él. Personalmente no me gustan los extremos y las generalidades,
prefiero estudiar cada caso y ve qué parte dejo en cada sitio para que quede
optimizado.

Un saludo
Salvador Ramos

www.helpdna.net (información sobre SQL Server y Microsoft .Net)
www.helpdna.net/acerca_de_salvador_ramos.htm


"Alfredo Novoa" escribió en el mensaje
news:
On Tue, 23 Oct 2007 10:21:38 +0200, "Salvador Ramos"
wrote:

La verdad que sobre este tema he oído opiniones muy muy diversas. Los
desarrolladores te darán razones para incluirlas fuera del servidor, y
posiblemente en este grupo tengamos más tendencia a incluirlas en el
servidor :-). Por eso te recomiendo que realices también la pregunta en
grupos de desarrollo y obtendrás un visión más amplia.



Nunca está mal conocer las opiniones de todo el mundo, pero no hay que
olvidar que la mayoría de los desarrolladores no tienen ni idea de
bases de datos y por lo tanto no hay que tener sus opiniones muy en
cuenta en estos casos.

Mi recomendación, un poco genérica eso si, es que toda la parte que tenga
que hacer uso intensido de acceso a datos se incluya en el servidor
(utilizando procedimientos almacenados, triggers, UDFs, ...), e incluso
parte de las reglas de negocio, sobre todo aquellas que se adapten más
fácilmente al lenguaje T-SQL. Y luego dejaría fuera del servidor las
reglas
de negocio más complejas que requieran más código complejo de implementar
en
T-SQL.



No lo entiendo T-SQL está mucho mejor preparado para implementar
lógica de negocio compleja que los lenguajes de programación de
aplicaciones.

La regla general es implementar TODA la lógica de negocio en el SGBD,
excepto en los casos en los que no sea posible debido a las
limitaciones del SGBD particular que estés usando.

Otra recomendación, lo que si me plantearía es utilizar algún generador de
código o crearte el tuyo propio, para tareas repetitivas, ya que siempre
habrá muchas tablas sin (o casi) sin lógica de negocio, las típicas tablas
auxiliares. Por ejemplo para crear procedimientos insert, update, delete
por
cada tabla ...



La generación de código es un síntoma de mal diseño.

http://c2.com/cgi/wiki?CodeGenerati...esignSmell



Saludos
Alfredo
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida