Seguimos buscando a Arshak. Ayudanos compartiendo!
Encuesta no oficial de docentes
Resultados de la encuesta no oficial de docentes
Probaste el SIGA Helper?

Donar $100 Donar $200 Donar $500 Donar mensualmente


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
C#: Linq vs Stored Procedures
Autor Mensaje
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #1
C#: Linq vs Stored Procedures
Bueno, aca para los capos de c# tengo un par de consultas


Hasta ahora en mi laburo use 3 formas para acceder a las DB

- stored procedures + dataset
- Tableadapters
- Linq

(no conozco tanto de c# para saber si hay mas combos locos)

Lo que mas use, igual, fue stored procedures + ds

Los tableAdapters toque un par de veces, y linq lo toque de costado, modificando un par de consultas ya hechas


Ahora bien, cual les parece mejor para utilizar en sus sistemas ?


Aca voy con la experiencia de cada uno, ya sea por
- Cantidad de Codigo escrito
- Facilidad de codeo/uso
- Reusabilidad de consultas/Datasets
- Uso de otras tecnologias (ej stored requiere usar SQL)
- Performance (he oido que linq es mas lento, pero es tipo.. radiopasillo[?])


Alguno ha utilizado combinaciones de estas ?
Cual es mas performante para apps web ? y para apps de escritorio ?

Por mi parte, linq me parecio muy groso al ppio pero ahora no me parece tan copado (?) ademas de que se me hace engorroso.
Sobre los TableAdapter debo decir que son muy grosos.
usar Stored da mucha comodidad, pero ante varias db se hace complicado el mantenimiento, ademas de que llevas algo de logica fuera del codigo
Algunos tips para cada uno de estos tipos ?


Por supuestos si hay formas similares de otras tecnologias, echen luz sobre el tema thumbup3

[Imagen: v34BEFt.gif]
(Este mensaje fue modificado por última vez en: 27-02-2012 19:55 por gonnza.)
27-02-2012 19:54
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Imakuni Sin conexión
Presidente del CEIT
Boxes tastes like mush
********

Ing. en Sistemas
Facultad Regional Córdoba

Mensajes: 7.021
Agradecimientos dados: 124
Agradecimientos: 129 en 85 posts
Registro en: Jul 2008
Mensaje: #2
RE: C#: Linq vs Stored Procedures
Pregunto y respondo desde un punto de vista totalmente ignorante:

¿LinQ no te daría la ventaja de poder hacer refactors más facilmente que tirando las querys?
27-02-2012 20:08
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #3
RE: C#: Linq vs Stored Procedures
Es una de las ventajas


de hecho, CREO que el VisualStudio te trae un par de herramientas que te refactorizan automaticamente consultas de linq (en vez de hacerlo a manopla)

[Imagen: v34BEFt.gif]
27-02-2012 20:09
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Imakuni Sin conexión
Presidente del CEIT
Boxes tastes like mush
********

Ing. en Sistemas
Facultad Regional Córdoba

Mensajes: 7.021
Agradecimientos dados: 124
Agradecimientos: 129 en 85 posts
Registro en: Jul 2008
Mensaje: #4
RE: C#: Linq vs Stored Procedures
En java al menos, ese es motivo suficiente por el cual conviene más usar Criteria (un linq pero mas objetoso y menos copado) que HSQL
27-02-2012 20:12
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Nicosunshine Ausente
Reclamó su premio!
( ͡° ͜ʖ ͡°)

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 131
Agradecimientos dados: 14
Agradecimientos: 17 en 4 posts
Registro en: Aug 2009
Mensaje: #5
RE: C#: Linq vs Stored Procedures
Yo tengo "experiencia" usando Stores + Dataset y LINQ.

Personalmente comparando los dos, linq es mejor porque permite usar stores muy fácil (lo tiras en el dbml y te genera solo el método con los parámetros de entrada y la clase de salida, si son necesarios) y te permite hacer queries simples sin necesidad de armar un store entero.

Aún así puede traer (en experiencia propia) un poco de mareo a la hora de saber que está haciendo cada cosa, porque al tener la mitad del código con stores y la mitad con queries de linq de vuelve un problemita de mantener.

En temas de velocidad, usando un perfilador, yo no noté diferencias, el código que genera linq está bien optimizado y normalmente funciona bien. No se que tul haciendo alguna consulta muy complicada. El problema que si trae es que le pega doscientas veces a la base y es más jodido de debuggear (con el store estás un toque más organizado).

Que se yo, como todo depende de lo que estés haciendo, igual LINQ no es solo tirar consultas, los métodos que provee para manejar Listas y Xml con lamba son alegría.
27-02-2012 20:45
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #6
RE: C#: Linq vs Stored Procedures
(27-02-2012 20:45)Nicosunshine escribió:  En temas de velocidad, usando un perfilador, yo no noté diferencias, el código que genera linq está bien optimizado y normalmente funciona bien. No se que tul haciendo alguna consulta muy complicada. El problema que si trae es que le pega doscientas veces a la base y es más jodido de debuggear (con el store estás un toque más organizado).

Le pega, o "si le pega" ? ahi no entendi. No se tanto del funcionamiento interno de linq como para saber cuantas veces accede a la db
Ahi no tendria perdida de performance ? siendo que entro mas veces a la db que un llamado a un stored

(27-02-2012 20:45)Nicosunshine escribió:  Que se yo, como todo depende de lo que estés haciendo, igual LINQ no es solo tirar consultas, los métodos que provee para manejar Listas y Xml con lamba son alegría.

claro, igual apuntaba especificamente a la consulta de db. Pero si se puede usar con lambdas (te morfaste la d =P) y xml, y si, son alegria Nyan

[Imagen: v34BEFt.gif]
27-02-2012 20:49
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Nicosunshine Ausente
Reclamó su premio!
( ͡° ͜ʖ ͡°)

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 131
Agradecimientos dados: 14
Agradecimientos: 17 en 4 posts
Registro en: Aug 2009
Mensaje: #7
RE: C#: Linq vs Stored Procedures
(27-02-2012 20:49)gonnza escribió:  Le pega, o "si le pega" ? ahi no entendi. No se tanto del funcionamiento interno de linq como para saber cuantas veces accede a la db
Ahi no tendria perdida de performance ? siendo que entro mas veces a la db que un llamado a un stored

Depende del caso, pero por ejemplo para hacer un Select * normalmente se transforma en un Select por cada campo que necesita, y como la conexión no se cierra, no es más lento.

(las lamba se la re bancan)
27-02-2012 20:57
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
ebric Sin conexión
Presidente del CEIT
nono ortiva
********

Análisis de Sistemas
Facultad Regional Buenos Aires

Mensajes: 3.113
Agradecimientos dados: 2
Agradecimientos: 18 en 13 posts
Registro en: Aug 2008
Mensaje: #8
RE: C#: Linq vs Stored Procedures
La posta es SP.

Cuando te das cuenta que un error en PROD seria facilmente solucionable si esa puta query estaria en la DB, te queres matar.

Es el amor el responsable, única guía del espíritu imperfecto
27-02-2012 22:38
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
shadow_mx Sin conexión
Presidente del CEIT
Lobo
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.090
Agradecimientos dados: 8
Agradecimientos: 8 en 3 posts
Registro en: Nov 2010
Facebook
Mensaje: #9
RE: C#: Linq vs Stored Procedures
La verdad que no use Linq todavia, pero me gusta mas tener los stores en la base bien diseñados, sin muchas lineas.

Leandro.


... Y mori queriendo ser libre, encontrar mi lado salvaje!!,
Ponerle alas a mi destino, romper los dientes de este engranaje! ♪♫
27-02-2012 23:00
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #10
RE: C#: Linq vs Stored Procedures
(27-02-2012 22:38)ebric escribió:  La posta es SP.

Cuando te das cuenta que un error en PROD seria facilmente solucionable si esa puta query estaria en la DB, te queres matar.

algun ejemplo ?



(27-02-2012 23:00)shadow_mx escribió:  La verdad que no use Linq todavia, pero me gusta mas tener los stores en la base bien diseñados, sin muchas lineas.

claro, a mi tambien, el tema se vuelve cuando usas un sistema en 100 bases, a veces el mantenimiento se vuelve un poco heavy (me pasa en el laburo)

[Imagen: v34BEFt.gif]
27-02-2012 23:11
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Agro Sin conexión
Presidente del CEIT
Su marca puede estar aquí
**********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 6.760
Agradecimientos dados: 252
Agradecimientos: 888 en 293 posts
Registro en: Jul 2008
Facebook Twitter
Mensaje: #11
RE: C#: Linq vs Stored Procedures
La posta es no usar ninguno de los dos. NHibernate (en alguna de sus variantes) FTW. Si necesitas ultraperformance, ahi podemos charlarlo y buscar otra cosa, pero para el 99% de las aplicaciones del mercado, va como piña. La posta es pensar en objetos y que alguien (Hibernate) se encargue de persistir eso.

Si chicos, es posible... no es un versito de la gente de paradigmas o TADP =)

[Imagen: digitalizartransparent.png]
28-02-2012 00:26
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
gonnza Sin conexión
User Verde

*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 17.356
Agradecimientos dados: 900
Agradecimientos: 887 en 356 posts
Registro en: Mar 2010
BlogSpot Google+ YouTube
Mensaje: #12
RE: C#: Linq vs Stored Procedures
[Imagen: serious-cat-meme-generator-cuentanos-mas...939620.jpg]


(posta, no lo digo en joda =P)

[Imagen: v34BEFt.gif]
28-02-2012 00:41
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Agro Sin conexión
Presidente del CEIT
Su marca puede estar aquí
**********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 6.760
Agradecimientos dados: 252
Agradecimientos: 888 en 293 posts
Registro en: Jul 2008
Facebook Twitter
Mensaje: #13
RE: C#: Linq vs Stored Procedures
Si vos tenes un objeto usuario... la posta es que el usuario tenga sus atributos y su metodos (loguearse, modificarse, crearse, etc) dentro de si mismo. Y quien persiste toda esa info? Hibernate. Vos simplemente creas el objeto y lo agregas a los que conoce Hibernate. Despues se los pedis a Hibernate. Si lo modificas, no tenes que decirle "guardalo". Es logico que lo va a hacer porque para eso modificaste el original.

La onda es asi, mapeas un objeto contra una tabla, y a su vez cada atributo del objeto contra una columna de la tabla. Si respetas las convenciones, lo hace solo. Y voalá (como diria Nanu), anda todo. Tenes una forma de mapear las relaciones 1-1, 1-N y N-N, formas de mapear herencias, etc. La onda es que vos pienses en objetos y relaciones entre ellos, y el framework hace el laburo por atras para que eso se persista.

Si a alguno le interesa nos robamos un aula de medrano algun finde y charlamos un par de estas cosas =P

[Imagen: digitalizartransparent.png]
28-02-2012 01:50
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
.py Sin conexión
Presidente del CEIT
gone
********

Análisis de Sistemas
Facultad Regional Buenos Aires

Mensajes: 4.224
Agradecimientos dados: 5
Agradecimientos: 132 en 86 posts
Registro en: Sep 2008
Mensaje: #14
RE: C#: Linq vs Stored Procedures
es simple: sp si la performance es critica, LINQ si queres que sea mas mantenible y OOP.

Si me preguntas a mi: con un equipo de desarrollo grande , te conviene sp. Cambiar algo no implica que tengas que tocar el build , solo modificar el server con la BD (y si haces las cosas bien, la DB no esta con el build). Ademas que cuando explote algo , vas a tener la ayuda de los DBAs , si es con Linq/Hibernate olvidate que te entendiendan.

Ademas los recursos humanos que saben usar SQL pelado sobran. Los que saben Hibernate/Linq? son la minoria.

[Imagen: 9zsRG7X.gif]
(Este mensaje fue modificado por última vez en: 28-02-2012 09:51 por .py.)
28-02-2012 09:42
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
shadow_mx Sin conexión
Presidente del CEIT
Lobo
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.090
Agradecimientos dados: 8
Agradecimientos: 8 en 3 posts
Registro en: Nov 2010
Facebook
Mensaje: #15
RE: C#: Linq vs Stored Procedures
Yo la verdad que tuve problemas con Hibernate, con objetos pesados y muchas acciones. Un proceso que para 2000 acciones se hacia en segundos, cuando las acciones superaban las 40 mil, el proceso tardaba mas 5 horas. Al final nunca lo pude resolver y saber con bien porque tardaba tanto. Era una combinacion entre Hibernate, las transacciones y los triggers de las tablas.... Era todo muy raro lo que pasaba.


PD: Igual me gustaria saber como se arman esas clases de hibernate en forma casi automatica, Mayormente use las DALS y me gustas xD.

Leandro.


... Y mori queriendo ser libre, encontrar mi lado salvaje!!,
Ponerle alas a mi destino, romper los dientes de este engranaje! ♪♫
28-02-2012 10:06
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)