Stored procedures o queries?

[Carlos Peix]

Hola,

Para que no se aburran en un sabado, tiro el siguiente, ya remañido, debate.

Un miembro de esta comunidad, del cual no quiero decir el nombre (pero si el apellido: Micheloni), ha dicho que no negocia el uso de stored procedures agregando otros comentarios relacionados con rendimiento.

Mi pregunta, para Leo pero tambien para los demas, es: tienen alguna correlacion reciente sobre el uso de stores procedures y la mejora de rendimiento en los queries?

Para acotar el debate, me refiero al mismo query, ejecutado en el interior de un SP o directamente. Por supuesto, asumamos que la ejecucion directa esta bien hecha (en caso de multiples ejecuciones, y utiliza la version "prepared", etc).

Gracias

----------------------------------
Carlos Peix

[Esteban Grinberg]

Si hablamos de SQL Server, no hay diferencias de performance visible si la query es una sola.

Distinto es el caso de procesos mas complejos, que implican consulta/insertado en multiples tablas, almacenamiento auxiliar en memoria, etc. En ese caso resolver todo eso en un solo store procedure suele ser mas rapido que muchas consultas a la base desde .NET, java o lo que fuese.

Para mi la ventaja de los store procedure estan del lado de la practicidad (resulta mucho mas facil actualizar un store procedure tanto en ambiente de desarrollo o produccion, que recompilar y deployar nuevamente una aplicacion porque una query tenia un bug).

2011/6/11 Carlos Peix <carlo...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

[Carlos Peix]

Hola Esteban,

2011/6/11 Esteban Grinberg <esteban....@gmail.com>

Si hablamos de SQL Server, no hay diferencias de performance visible si la query es una sola.

Si, a esto me refiero, ya comparar lo que decis a continuacion seria un error porque son dos cosas bien distintas.

Gracias 

----------------------------------
Carlos Peix

 

[Daniel Cazzulino]

y creo q la prioridad numero uno antes de empezar a hablar es ponernos de acuerdo en la terminologia.

LA query o EL query?!?!?! :PPP

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

2011/6/11 Carlos Peix <carlo...@gmail.com>

--

[Carlos Peix]

Kzu,

Se nota que esta usted relajado hoy. Pongamos que hablamos de "the query"

Abrazo

----------------------------------
Carlos Peix

2011/6/11 Daniel Cazzulino <dan...@cazzulino.com>

[Juan Carlos Quijano Abad]

Buenas,

Yo intento no usar nunca procedimientos. Siempre intento hacerlo en código.

Pero esto es tan flexible como la necesidad de rendimiento del proyecto.

Pero a mí, personalmente,solo me han producido enormes dolores de cabeza que personas fuera del proyecto tengan acceso a romperlo todo de una manera tan fácil como modificar un procedimiento almacenado. (¿sera mala suerte?)

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

Blog de opinión social

Blog de World of Warcraft

Blog de Tiro con Arco

[Marcos Mellibovsky]

En mi opinon que los sp son mas rapido es un mito, creo que por un lado  gente de microsoft lo afirmaba y por otro lado al hablar de The Query no se especifica si eston son parametrizados o no. En la epoca que se popularizo el mito eran comun ver queries sin parametrizar. Si ejecutamos:

a) SELECT nombre FROM Customers WHERE ID = 5 

b) SELECT nombre FROM Customers WHERE ID = 6 

Son 2 queris distintas, el motor recibe el textoSQL, lo compara con los que ya ejecuto y resulta ser diferente, por lo tanto compila ambos query. Si en cambio ejecutamos:

a) SELECT nombre FROM Customers WHERE ID = @Id 

b) SELECT nombre FROM Customers WHERE ID = @Id 

El query es el mismo, el motor lo detecta y no vuelve a compilar en la ejecucion b).

Según entiendo una vez compilado tanto para el sp como para el TSql la ejecucion esta transformada en una especie de Expresion Tree y no se sabe si viene de un sp o tsql.

Seguramente quien afirmo orginalmente que los sp eran mas rapidos se referia a los sp contra query sin parametrizar lo cual es correcto. Quienes escucharon la afirmacion la sacaron de contexto generalizandola y ahi surgio el error.

Hace algunos años (2007) para un charla debate similar hice una serie de tests sobre sql2005 para desmostrarlo y si bien no  fue hecho con rigor cientifico,creo que fue totalmente valido. Adjunto algunas resultados. Recuerdo que la difernecia entre sp contra sql parametrizado variaba levemente debido a que la pc de prueba no era un servidor dedidado a las pruebas sino que tenia otras cosas que hacian variar levemente el resultado.

 

Ademas, mientras se ejecutaban los queries se analizaban los contadores de performance de Compilaciones y recompilaciones por segundo y se veia que tanto para el sp como para el sql parametrizado habia 1 sola compilacion la primera vez.

Saludos

Ing. Marcos Mellibovsky
ARSoft Consultoría Informática
mel...@arsoft.com.ar
0351 155630801
msn:mellibov...@hotmail.com

2011/6/12 Juan Carlos Quijano Abad <juancarl...@gmail.com>

[José F. Romaniello]

100% de acuerdo con lo que dijo Marcos.

Por otro lado; ese tema de que se pueden tocar los SPs en producción
me da escalofrios, como así también quien dijo que no usa sps por
miedo a que la gente los modifique..ya que si alguien puede modificar
un sp es probable que también puede modificar el nombre de una tabla.

El 12/06/11, Marcos Mellibovsky <mel...@gmail.com> escribió:

>> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
>> Blog de opinión social <http://unmalnacido.blogspot.com/>
>> Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
>> Blog de Tiro con Arco <http://litelllon.blogspot.com/>

--
Enviado desde mi dispositivo móvil

[José F. Romaniello]

Una cosa más; hace mucho vi que un dba llamaba SP también a lo que
llamamos query parametrizada. No se si es comun esto

El 12/06/11, Marcos Mellibovsky <mel...@gmail.com> escribió:

>> Blog de .Net y Gestión de proyectos <http://1poquitodtodo.blogspot.com/>
>> Blog de opinión social <http://unmalnacido.blogspot.com/>

>> Blog de World of Warcraft <http://historiasdesdeazeroth.blogspot.com/>
>> Blog de Tiro con Arco <http://litelllon.blogspot.com/>

--

[Esteban Grinberg]

Pero eso de que uno puede modificar los SP en produccion es relativo si hacemos las cosas bien, o sea, asignarle permisos de solo ejecucion a un SP, imposibilitando que nadie (menos el dba y los desarrolladores) tengan posibilidad de modificar un

store procedure.

Pero el ahorro de tiempo que implica modificar un store en comparacion con deployar una aplicacion no tiene precio (y ni que hablar si la aplicación es Winform y tenes que pedirle a los usuarios que la reinstalen)...

2011/6/12 José F. Romaniello <jfroma...@gmail.com>

[Marcos Mellibovsky]

Coincido con esteban en que muchas a veces se pueden corregir cosas (lo he hecho unas cuantas veces) sin deplayar toda la app. Un ejemplo simple es por ejemplo, ponerle un order by a un query o algo asi de simple. Si desarrollamos poniendo poca o nada de logica en los sp esto nos sirve solo para estos pequeños cambios. En el caso de reportes tambien me ha sido util tocar el sp y no deployar la app. Por otra lado, si la seguridad es importante los sp son una muy buena opción. Tengo un caso de un sistema winform que esta distribuido fisicamente en lugar donde hay 1 sola PC con un operador, con una aplicacion anterior hubo problemas de fraude porque el operador (estudiante de sistemsa) entraba a la base y cambiaba cosa a mano. Ahora se usan sp para todo el acceso y el operador ni siquiera puede hacer select sobre ninguna tabla.

En mi caso, en este momento prefiero usar solo los sp para algunas cosas bastante especifica como seguridad o donde llevar todos los datos necesarios para un proceso a la app es muy costoso contra procesarlo dentro del motor.

 

Ing. Marcos Mellibovsky

ARSoft Consultoría Informática
mel...@arsoft.com.ar
0351 155630801
msn:mellibov...@hotmail.com

2011/6/12 Esteban Grinberg <esteban....@gmail.com>

[Carlos Peix]

Hola,

Gracias por los comentarios.

2011/6/12 Marcos Mellibovsky <mel...@gmail.com>

Coincido con esteban en que muchas a veces se pueden corregir cosas (lo he hecho unas cuantas veces) sin deplayar toda la app. Un ejemplo simple es por ejemplo, ponerle un order by a un query o algo asi de simple.

No digo que no lo haya hecho ni que no lo vuelva a hacer, pero hay que tomar en cuenta que estamos modificando la aplicacion sin correr los tests...

----------------------------------
Carlos Peix

[Daniel Cazzulino]

yo creo q la velocidad y compile-time safety adicional q te da hacer los queries desde C# (obvio si estas usando Linq to Algo) te permite satisfacer las necesidades cambiantes del negocio mas efectivamente q con la ceremonia de no solo compile sino deploy de SPs.

Asumo q unit tests corres en ambos casos, asi q no deberia ser ese un motivo principal para elegir uno u otro approach.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

2011/6/12 Carlos Peix <carlo...@gmail.com>

[José F. Romaniello]

Yo trabaje durante 5 años en una empresa donde hicimos un sistema en vb6 de esa manera, usabamos SP solo para reportes (crystal) y en ese contexto puede llegar a funcionar pero, 

las consultas son parte del negocio de la aplicación...

[José F. Romaniello]

El 12 de junio de 2011 12:13, Daniel Cazzulino <dan...@cazzulino.com> escribió:

Asumo q unit tests corres en ambos casos, asi q no deberia ser ese un motivo principal para elegir uno u otro approach.

En los proyectos que tuve el lujo de ver que se tocan SPs en producción... puedo asegurarte que no había unit tests para eso

[Leonardo Micheloni]

Hola mi nombre es Leonardo M,

 El plan de ejecución (en sqlserver) no se calcula con cada ejecución ya es costoso, por lo tanto un SP que utiliza el mejor plan siempre va a ser más rápido.

En donde trabajo ofrecemos servicios a través del software que hacemos. 

En el sistema particular por el que hice el comentario "no usar sps no es negociable" existen muchas peculiaridades, pongo en contexto.

Ingresan muchos documentos a la base contínuamente, estos tiene que pasar por varios procesos que actualizan parte de sus datos, por otro lado los clientes que ponen esos documentos quieren ver todo el tiempo en qué estado están y quieren tener el documento procesado muy rápido.

Cada índice que existe se estudia cuidadosamente, ya que los usuarios se comportan de manera extrañas y utilizan filtros inesperados, también se comportan de modos extraños en la forma de enviar documentos, a veces poco, otras todos juntos suben muchos, por lo tanto cada índice mejora búsquedas (el cliente te llama para saber por qué tarda tanto en responder un grilla) pero perjudica los inserts / updates (empeora el tiempo en que el documento sube-se procesa-se baja). Se está evaluando poner una tabla stage pero demoraría la disponibilidad del documento.

Les digo por experiencia que una consulta nueva (un select) que no utiliza el índice adecuando puede romper todo, ni hablar de un update, etc.

Sumado a esto, el sistema evoluciona mucho (el año pasado tuvimos más de 50 versiones) entonces hay muchas nuevas funcionalidades y cambios en el comportamiento de los clientes.

Hoy en día siempre se utilizan SPs y siempre son revisados los planes de ejecución y los índices utilizados por una persona (que vamos a llamarle DBA, la D es por el inglés Devil)

Ese es el esquema actual, es tan celoso el tema de la performance que se revisan las estadísticas de objetos de sql para detectar "elefantes" de consumo, también se monitorea el consumo de CPU y RAM del sqlserver y el acceso a disco, etc.

Por supuesto que no hay lógica de negocios en los SPs, tampoco la idea es que se hagan cambios en producción, si se usan como filtro de seguridad, los servicios se conectan con autenticación integrada y solo pueden ejecutar los SPs permitidos, nadie puede hacer una query en producción (excepto el DBA)

Bueno, esa es la historia señor Peix (tampoco voy a usar el nombre para no generar conflictos) y una cosas más, a mí tampoco me gusta que sea así, pero realmente no veo opción.

 

2011/6/12 José F. Romaniello <jfroma...@gmail.com>

El 12 de junio de 2011 12:13, Daniel Cazzulino <dan...@cazzulino.com> escribió:

Asumo q unit tests corres en ambos casos, asi q no deberia ser ese un motivo principal para elegir uno u otro approach.

En los proyectos que tuve el lujo de ver que se tocan SPs en producción... puedo asegurarte que no había unit tests para eso

--

[Carlos Peix]

Hola Leo,

2011/6/12 Leonardo Micheloni <leonardogabr...@gmail.com>

Bueno, esa es la historia señor Peix (tampoco voy a usar el nombre para no generar conflictos) y una cosas más, a mí tampoco me gusta que sea así, pero realmente no veo opción.

Si, totalmente de acuerdo, cada software es un mundo. Gracias por el detalle.

----------------------------------
Carlos Peix

[José F. Romaniello]

El 12 de junio de 2011 16:26, Leonardo Micheloni <leonardogabr...@gmail.com> escribió: 

Hoy en día siempre se utilizan SPs y siempre son revisados los planes de ejecución y los índices utilizados por una persona (que vamos a llamarle DBA, la D es por el inglés Devil)
Ese es el esquema actual, es tan celoso el tema de la performance que se revisan las estadísticas de objetos de sql para detectar "elefantes" de consumo, también se monitorea el consumo de CPU y RAM del sqlserver y el acceso a disco, etc.

"Siempre" en esa frase suena a mucho... Tampoco los RDBMS modernos son tan estúpidos como para especificarles SIEMPRE el plan de ejecución..

Alguien ha detallado muchos puntos importantes acá, a continuación pego todo el texto;

NOTE that this is a general look at stored procedures not regulated to a specific DBMS. Some DBMS (and even, different versions of the same DBMS!) may operate contrary to this, so you'll want to double-check with your target DBMS before assuming all of this still holds.
I've been a Sybase ASE, MySQL, and SQL Server DBA on-and off since for almost a decade (along with application development in C, PHP, PL/SQL, C#.NET, and Ruby). So, I have no particular axe to grind in this (sometimes) holy war.
The historical performance benefit of stored procs have generally been from the following (in no particular order):

• Pre-parsed SQL

• Pre-generated query execution plan

• Reduced network latency

• Potential cache benefits

Pre-parsed SQL -- similar benefits to compiled vs. interpreted code, except on a very micro level.
Still an advantage? Not very noticeable at all on the modern CPU, but if you are sending a single SQL statement that is VERY large eleventy-billion times a second, the parsing overhead can add up.
Pre-generated query execution plan. If you have many JOINs the permutations can grow quite unmanageable (modern optimizers have limits and cut-offs for performance reasons). It is not unknown for very complicated SQL to have distinct, measurable (I've seen a complicated query take 10+ seconds just to generate a plan, before we tweaked the DBMS) latencies due to the optimizer trying to figure out the "near best" execution plan. Stored procedures will, generally, store this in memory so you can avoid this overhead.
Still an advantage? Most DBMS' (the latest editions) will cache the query plans for INDIVIDUAL SQL statements, greatly reducing the performance differential between stored procs and ad hoc SQL. There are some caveats and cases in which this isn't the case, so you'll need to test on your target DBMS.
Also, more and more DBMS allow you to provide optimizer path plans (abstract query plans) to significantly reduce optimization time (for both ad hoc and stored procedure SQL!!).
WARNING Cached query plans are not a performance panacea. Occasionally the query plan that is generated is sub-optimal. For example, if you send SELECT * FROM table WHERE id BETWEEN 1 AND 99999999, the DBMS may select a full-table scan instead of an index scan because you're grabbing every row in the table (so sayeth the statistics). If this is the cached version, then you can get poor performance when you later send SELECT * FROM table WHERE id BETWEEN 1 AND 2. The reasoning behind this is outside the scope of this posting, but for further reading see:http://www.microsoft.com/technet/prodtechnol/sql/2005/frcqupln.mspx andhttp://msdn.microsoft.com/en-us/library/ms181055.aspx and http://www.simple-talk.com/sql/performance/execution-plan-basics/
"In summary, they determined that supplying anything other than the common values when a compile or recompile was performed resulted in the optimizer compiling and caching the query plan for that particular value. Yet, when that query plan was reused for subsequent executions of the same query for the common values (‘M’, ‘R’, or ‘T’), it resulted in sub-optimal performance. This sub-optimal performance problem existed until the query was recompiled. At that point, based on the @P1 parameter value supplied, the query might or might not have a performance problem."
Reduced network latency A) If you are running the same SQL over and over -- and the SQL adds up to many KB of code -- replacing that with a simple "exec foobar" can really add up. B) Stored procs can be used to move procedural code into the DBMS. This saves shuffling large amounts of data off to the client only to have it send a trickle of info back (or none at all!). Analogous to doing a JOIN in the DBMS vs. in your code (everyone's favorite WTF!)
Still an advantage? A) Modern 1Gb (and 10Gb and up!) Ethernet really make this negligible. B) Depends on how saturated your network is -- why shove several megabytes of data back and forth for no good reason?
Potential cache benefits Performing server-side transforms of data can potentially be faster if you have sufficient memory on the DBMS and the data you need is in memory of the server.
Still an advantage? Unless your app has shared memory access to DBMS data, the edge will always be to stored procs.
Of course, no discussion of Stored Procedure optimization would be complete without a discussion of parameterized and ad hoc SQL.
Parameterized / Prepared SQL
Kind of a cross between stored procedures and ad hoc SQL, they are embedded SQL statements in a host language that uses "parameters" for query values, e.g.:
SELECT .. FROM yourtable WHERE foo = ? AND bar = ?
These provide a more generalized version of a query that modern-day optimizers can use to cache (and re-use) the query execution plan, resulting in much of the performance benefit of stored procedures.
Ad Hoc SQL Just open a console window to your DBMS and type in a SQL statement. In the past, these were the "worst" performers (on average) since the DBMS had no way of pre-optimizing the queries as in the parameterized/stored proc method.
Still a disadvantage? Not necessarily. Most DBMS have the ability to "abstract" ad hoc SQL into parameterized versions -- thus more or less negating the difference between the two. Some do this implicitly or must be enabled with a command setting (SQL server: http://msdn.microsoft.com/en-us/library/ms175037.aspx , Oracle: http://www.praetoriate.com/oracle_tips_cursor_sharing.htm).
Lessons learned? Moore's law continues to march on and DBMS optimizers, with every release, get more sophisticated. Sure, you can place every single silly teeny SQL statement inside a stored proc, but just know that the programmers working on optimizers are very smart and are continually looking for ways to improve performance. Eventually (if it's not here already) ad hoc SQL performance will become indistinguishable (on average!) from stored procedure performance, so any sort of massive stored procedure use ** solely for "performance reasons"** sure sounds like premature optimization to me.
Anyway, I think if you avoid the edge cases and have fairly vanilla SQL, you won't notice a difference between ad hoc and stored procedures.

[Marcos Mellibovsky]

En algunos RDBMS los sp se guardan compilados, en sql server no. Para mi, desde el punto de vista de performance, en sql server un sp es solo un alias de un TSQL. El plan de ejecucion se elige para el resultado de la compilacion. El resultado de la compilacion es el mismo para el sp que para el TSQL que tiene adentro el sp. En ambos casos se compila en la primera ejecucion.  

Ing. Marcos Mellibovsky
ARSoft Consultoría Informática
mel...@arsoft.com.ar
0351 155630801
msn:mellibov...@hotmail.com

--

[Esteban Grinberg]

Leyendo la problemática de Leonardo, veo que las ventajas de los SP me parece que son mas de lado operativo, que técnicas.

O sea, si un sistema sufre cambios muy seguido y es muy sensible al uso de indices y querys muy optimizadas, me parece un despropósito andar deployando la aplicación por cada prueba de tunning de query que se hace. 

Pero del lado de performance, en ese escenario no hay diferencias. El SQL Server guarda el plan de ejecución de las consultas pre parametrizadas.

[Carlos Peix]

Hola Esteban,

On Sun, Jun 12, 2011 at 9:51 PM, Esteban Grinberg <esteban....@gmail.com> wrote:

Leyendo la problemática de Leonardo, veo que las ventajas de los SP me parece que son mas de lado operativo, que técnicas.

O sea, si un sistema sufre cambios muy seguido y es muy sensible al uso de indices y querys muy optimizadas, me parece un despropósito andar deployando la aplicación por cada prueba de tunning de query que se hace. 

Pero del lado de performance, en ese escenario no hay diferencias. El SQL Server guarda el plan de ejecución de las consultas pre parametrizadas.

Creo que es un buen resumen, pienso exactamente igual. Me imaginaba este escenario: "no hace diferencia en velocidad pero Leo hace bien en usarlos", pero a mi me gusta cuestionarme todo el tiempo para que no nos llenemos de mitos.

Buena semana a todos

----------------------------------

Carlos Peix

[Juan Carlos Quijano Abad]

Buenas,

Pero si tienes las Querys metidas dentro de una DAL que compilada en una DLL, no deberíamos tener problemas en hacer un deploy solamente de ello sin necesidad de tener que actualizar toda la aplicación. Y sigues evitando que un manazas te rompa la aplicación por tocar donde no debe. (Si no existieran manazas le mundo sería más feliz... ;))

--

Un saludo

Juan Quijano

 

Blog de .Net y Gestión de proyectos

Blog de opinión social

Blog de World of Warcraft

Blog de Tiro con Arco

--

[Marcos Mellibovsky]

Ademas si tenes un Devil BA que seguramente no le hace mucho al C# y quiere superperfeccionar los queries es lógico que imponga el uso de sp.

 
Ing. Marcos Mellibovsky
ARSoft Consultoría Informática
mel...@arsoft.com.ar
0351 155630801
msn:mellibov...@hotmail.com

On Sun, Jun 12, 2011 at 9:51 PM, Esteban Grinberg <esteban....@gmail.com> wrote:

[Leandro de los Santos]

Mi humilde opinión a esto… Como siempre, todo depende.

 

Si uno tiene una aplicación totalmente centrada a manejar datos y con alto volumen el lugar más eficiente va a ser siempre la base de datos por una cuestión lógica, si todo lo que hago nace a partir de información que tengo en la DB y muere también en la DB cualquier capa en el medio mete tiempos adicionales.

 

Yo tuve la experiencia de trabajar en una aplicación de alto volumen (una cartera de 400,000.- pólizas vigentes las cuales había que cobrar todos los meses mediante débitos, reintentos, etc.). Al haber metido la gran mayoría de las transacciones en la DB cuando tuve que hacer los procesos programar store procedures lograba tiempos de proceso muy bajos (5 minutos como mucho para generar todas las cuotas de la cartera incluyendo su respectiva cotización, tiempos similares en hacer los procesos de cobranzas que eran diarios).

 

En definitiva, si lo que necesitamos es performance y las ventanas que uno tiene de procesamiento son realmente bajas la implementación más eficiente va a estar en la base de datos (o haciendo cosas muy pegadas a la DB como TXT y BCP o SSIS). Luego, en estos escenarios como la herramienta de programación en la DB son las store procedure, me parece que aplica el mismo criterio que en cualquier otro lenguaje, mejor diseñado y modularizado estén mis store procedures, más fácil va a ser programar lo que tenga que hacer.

 

También me parece que todas las bases de datos siempre entendieron que deben ser el punto más eficiente de procesamiento, y por eso desde siempre podías subir funciones hechas en C o similar, y ahora tenes capacidad de subir lógicas en java o en .net según el producto. De esta forma podes montar lógicas de negocio como componentes en la base e invocarlas directamente desde una STP (nunca lo hice, esperaría nunca tener que necesitarlo, pero si realmente fuera crítica la performance, creo que sería una opción a evaluar).

 

Obviamente, si puedo elegir, prefiero un ORM y programar en C#, pero creo que hay una regla que siempre aplica y es que el código más eficiente, en general es el más difícil de mantener. Igualmente nunca note la diferencia entre ejecutar un store procedure o tirar un query, me parece que en ambos casos la diferencia siempre la vas a notar en el correcto modelado de tus tablas, índices y demás cuestiones que hacen a la consulta. En definitiva un query mal hecho sobre un modelo mal diseñado va a andar mal este donde esté, y ahí es donde realmente hay diferencia (hablamos de milisegundos a directamente colgar todos los usuarios).

 

En lo personal, me parece que es una cuestión de como uno enfoca el problema, por ejemplo si estamos haciendo algo intensivo y contando las milésimas, quizás una store procedure sea más eficiente, pero si realmente te interesa tanto el milisegundo, quizás la pregunta sería porque llamas tanto a esa store procedure, si es que no te conviene hacer otro enfoque… Por ejemplo, si tenes una iteración que llama mucho a una STP que inserta y hace varias cosas capaz que la solución es insertar en una tabla temporal y luego correr una única stp que pase a producción haciendo todo junto (en lugar de medir el tiempo de cada invocación, a mí siempre me dio resultado medir la forma de hacer la menor cantidad de invocaciones posibles). No sé si me explico, pero creo que en base de datos lo que más diferencia da es la forma es el diseño que le das a tu problema entendiendo que hay un cliente-servidor y no tanto el mecanismo especifico que estés usando.

 

Ah, y para ganar más amigos… No creo en los Devil BA, me parece que es gente que tiene responsabilidades que chocan con las responsabilidades que tiene el que desarrolla y su función a veces es ponerse en molesto, pero en mi experiencia con ellos, si uno entiende el objetivo del DBA y negocia con él la forma de acompañar dicho objetivo en tu solución, son unos aliados muy útiles a la hora de solucionar problemas o diseñar tus soluciones. Lo mismo aplica con infraestructura o incluso un sector de arquitectura de un cliente. Están para algo y uno tiene que buscar la forma de no generar un conflicto con ellos, nos guste o no, no dejan de ser un tipo de usuario de nuestro desarrollo que tienen sus requerimientos y pueden meter sus errores en el sistema.

 

Saludos

Leandro de los Santos

[Leonardo Micheloni]

si, siempre suena a mucho, lo cambio por "casi siempre" por supuesto que mis conocimientos de bases de datos son muy básico y además del DBA interno nos visita cada tanto un conocido gurú MPV que siempre que yo cuestiono algo similar me tira una demostración en la cara y me deja dibujado, claro que es una pelea desigual :) , no me gusta decir siempre por supuesto que no, todas las veces que lo he visto pasó tal cual, y no siempre los productos se comportan según la documentación.

On Sun, Jun 12, 2011 at 4:52 PM, José F. Romaniello <jfroma...@gmail.com> wrote:

--

[Leonardo Micheloni]

por supuesto que lo de Devil era una humorada :)

El tema de que todas las consultas se puedan auditar para determinar su usan un plan de ejecución correcto pesa mucho

2011/6/13 Juan Carlos Quijano Abad <juancarl...@gmail.com>

[Leonardo Micheloni]

Si, es el día de hoy que estamos haciendo cambios en el diseño ya que por la evolución del negocio las cosas fueron quedando "incómodas" para los requerimientos de volumen y velocidad de hoy en día.

2011/6/13 Leandro de los Santos <delossant...@gmail.com>

[Carlos Peix]

Hola Leandro,

Ya nos adentramos en otro tema, tambien interesante pero mas subjetivo. Hace ya unos 8 años debatimos en alguna lista con un desarrollador centrado en base de datos (algo mas que un DBA) con un caso similar a lo que mencionas en cotizacion de polizas, era un ajuste de costos.

No es posible tomar posicion general en arquitectura, mucho menos con tan poca informacion, pero si creo que es importante debatir sobre los pros y contras de cada diseño.

Los pros de una solucion como la que describis ya fueron expuestos en tu mail, el de Leo y algunos mas. Sin embargo, creo que es importante evaluar algunas contras, como por ejemplo, la escalabilidad.

En general solemos trabajar con soluciones con un unico servidor de base de datos, las operaciones que nos dan el maximo en velocidad lo hacen a costa de un requerimiento de recursos en el servidor. Tambien entiendo que el proceso mediate queries, basado en conjuntos, puede generar mas bloqueos que otros procesos unitarios.

Entonces trato de evaluar tambien soluciones alernativas cuando necesito escalabilidad, soluciones que requieren, usualmente, diseños diferentes.

Siempre la escalabilidad viene acompañada de una perdida de velocidad en procesos puntuales, pero ganamos en otros aspectos.

----------------------------------
Carlos Peix

2011/6/13 Leandro de los Santos <delossant...@gmail.com>

Mi humilde opinión a esto… Como siempre, todo depende.

[Leonardo Micheloni]

es interesante lo que decís Carlos, un claro ejemplo de que el modelo relacional es, para trabajar con una aplicación OO, al menos cuestionable es que hace un tiempo atrás pusimos un índice en una de las tablas core tipo POID (un guid más específicamente) justamente para reducir joins complicados y lentos..

Me parece que la escalabilidad de un RBMS va muy por otro lado que OO, como que es un punto en donde se nota mucho la impedancia de los modelos

2011/6/13 Carlos Peix <carlo...@gmail.com>

--

[Leandro de los Santos]

Y si… En general la mejor solución siempre está a mitad de camino de todas las variables que tenes que considerar (o en el peso correcto de cada una, pero nunca las variables pesan cero). Eficiencia vs escalabilidad o mantenimiento del código, evolución del negocio, etc…

 

Hasta me atrevo a tirar un teorema… “El dolor de cabeza que tenes hoy es directamente proporcional a la performance que tiene el código que escribiste ayer”… Por suerte el hardware evoluciona, así que cada vez uno tiende a buscar menores dolores de cabeza.

 

De paso, el caso que comente son seguros de robo en cajero vendidos que venden los bancos. Costo fijo por segmento del cliente… Por el volumen, lo que hacía era calcular el costo de cada segmento de clientes en el Middle tier y por cada segmento disparaba una STP para generarle las cuotas. De esta forma me quedaba a “medio camino”, no era 100% en la db, la lógica de costo podría evolucionar en la capa de negocio y como el negocio es de volumen, siempre iba a poder tener un segmento importante de clientes al que le correspondiera dicho precio… Ahí es donde venía la optimización usando la DB (una invocación para un precio, muchos clientes con sus cuotas generadas).

 

Saludos

 

From: altnet-...@googlegroups.com [mailto:altnet-hisp...@googlegroups.com] On Behalf Of Carlos Peix
Sent: Monday, June 13, 2011 9:27 AM
To: altnet-...@googlegroups.com
Subject: Re: [altnet-hispano] Stored procedures o queries?

 

Hola Leandro,

--

[kv-tRoy [5k]]

Tiene mucho que ver en que proceso es imprescindible utilizar un store procedure y no simplemente un query. Por le general en mi humilde opinión utilizó los store procedures para ejecutar procesos complicados que un simple query no puede resolver.

 

saludos!

El 11 de junio de 2011 16:39, Carlos Peix <carlo...@gmail.com> escribió:

Hola,

Para que no se aburran en un sabado, tiro el siguiente, ya remañido, debate.

Un miembro de esta comunidad, del cual no quiero decir el nombre (pero si el apellido: Micheloni), ha dicho que no negocia el uso de stored procedures agregando otros comentarios relacionados con rendimiento.

Mi pregunta, para Leo pero tambien para los demas, es: tienen alguna correlacion reciente sobre el uso de stores procedures y la mejora de rendimiento en los queries?

Para acotar el debate, me refiero al mismo query, ejecutado en el interior de un SP o directamente. Por supuesto, asumamos que la ejecucion directa esta bien hecha (en caso de multiples ejecuciones, y utiliza la version "prepared", etc).

Gracias

----------------------------------
Carlos Peix

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a altnet-hispan...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/altnet-hispano?hl=es.

--
Mess with the best, die like the rest!!
blog: http://vyktor5k.blogspot.com

blog: http://accesscom.com.mx/blogs

twitter: @vyktor5k

[Andres Aiello]

Recien me comentaron de este debate y me tenté de entrar y dar mi
opinion.
Creo que hay muchas cuestiones a tener en cuenta y no suele haber una
respuesta de "lo mejor es tal cosa", depende mucho de cada sistema.
A nivel performance si la query es única como el escenario que se
plantea y está parametrizada ambas tendrán el plan de ejecución
precompilado desde la primera vez, pero un stored va a ser mas facil
de adminsitrar si hay muchos cambios.
Otro tema a tener en cuenta es la seguridad, un stored me va a hacer
mas simple incorporar auditorias (dejando de lado las auditorias
propias de 2008, repito, mas simple, no que no se pueda de otra
forma), y tambien me va a permitir hacer que sea mas robusto si voy a
hacer controles simples de validación, por ejemplo controlar cierta
integridad de los parametros. En el caso "the query" debería tener
permiso de DELETE, por ejemplo, sobre la tabla, permitiendo que
potencialmente esa cuenta si cae en otras manos sea peligrosa, en
cambio en el stored puedo solamente dar permiso de ejecucion a dicho
stored y este se encarga de hacer el delete, limitando la entrada y
pudiendo validar mas las cosas.
Saludos,
Andrés

On 13 jun, 11:32, "kv-tRoy [5k]" <pwma...@gmail.com> wrote:
> Tiene mucho que ver en que proceso es imprescindible utilizar un store
> procedure y no simplemente un query. Por le general en mi humilde opinión
> utilizó los store procedures para ejecutar procesos complicados que un
> simple query no puede resolver.
>
> saludos!
>

[Walter Poch]

Buenas a todos, 

Creo que como ya se ha planteado que los SP, mejoran la performance pero indirectamente:

• son más fáciles de auditar y detectar cuellos de botella
• generalmente pasan revisiones de más de una persona (aka DBA)

Nosotros los usamos por el tema de DBA, y seguridad. Facilitan un manejo bastante granular de permisos.

Todo esto no es exclusivo de los SPs, pero veo como que por default los SPs llevan a ese modo de trabajo; en cambio por lo menos lo que yo conozco usando LINQ muchas veces ni se revisan los execution plans.

Saludos,

Saludos,

Walter G. Poch
Sr. .Net Developer
--------------------------------------------
Cell: +54 (9 341) 3353273
walte...@gmail.com

[Leonardo Micheloni]

entonces si quiero auditar que las consultas aprovechen los índices + limitar permisos de ejecución por identidad, es conveniente usar SPs?

2011/6/13 Walter Poch <walte...@gmail.com>

[Carlos Peix]

Hola Leo

2011/6/13 Leonardo Micheloni <leonardogabr...@gmail.com>

entonces si quiero auditar que las consultas aprovechen los índices + limitar permisos de ejecución por identidad, es conveniente usar SPs?

Lo de auditar el uso de indices, desconozco. De todas maneras quiero aclarar que mi opcion default no es usar IQueryable y linq por toda la aplicacion. Yo prefiero hacer una suerte de "stored procedures" en codigo usando queries encapsulados (ya sea en repositorios o en EQO). Ambos se pueden probar y verificar uso de indices.

Creo que hay que tomar en cuenta el entorno. No es lo mismo si tenes clientes desktop que se conectan a tu BD directamente que si tenes una aplicacion web o te conectas mediante una capa de servicios hosteada en WCF.

El problema de acceder directo con la identidad del usuario en aplicaciones Web es la escalabilidad, los pools de conexiones casi no sirven en ese escenario.

En una aplicacion desktop tampoco pero es esperable tener menos cantidad de conexiones a la base de datos. 

----------------------------------
Carlos Peix

[Leonardo Micheloni]

Usar IQueriable por todos lados es lo mismo que sql embebido, eso es claro, se hablo en varias VAN, volviendo a la raíz de mi comentario inicial, no veo entonces la ventaja de usar EQO si tengo que usar si o si SP, lo veo muy claro si uso una interfaz para esconder una consulta tipo Criteria, en en este caso no, si me pueden desasnar al respecto

2011/6/14 Carlos Peix <carlo...@gmail.com>

[Carlos Peix]

Hola Leo,

2011/6/14 Leonardo Micheloni <leonardogabr...@gmail.com>

Usar IQueriable por todos lados es lo mismo que sql embebido, eso es claro, se hablo en varias VAN, volviendo a la raíz de mi comentario inicial, no veo entonces la ventaja de usar EQO si tengo que usar si o si SP, lo veo muy claro si uso una interfaz para esconder una consulta tipo Criteria, en en este caso no, si me pueden desasnar al respecto

Lo que te permite EQO es usar desde tu codigo cualquier query independiente de la implementacion, incluso cambiar la implementacion cuando quieras, hasta dependiendo de las particularidades de la instalacion.

En algunos resolveras con un SP, en otros con un linq, en otros con una lectura de archivo, en otro con una consulta a un WS con cache incluido, etc.

Siempre desde afuera, desde tus servicios o dominio, ves lo mismo.

Detras de la interfaz podes poner cualquier cosa, es una abstraccion muy parecida a la que te da el repositorio, pero exclusiva para queries.

La utilidad que pueda tener esto depende de cada proyecto.

----------------------------------

Carlos Peix

[cibrax]

"El problema de acceder directo con la identidad del usuario en
aplicaciones
Web es la escalabilidad, los pools de conexiones casi no sirven en
ese
escenario. "

Carlos, este escenario ya no es demasiado cierto en estos tiempos.
ASP.NET por ejemplo no impersona a los usuarios por default y es muy
raro el caso en que necesites realmente impersonar, todo corre siempre
bajo el usuario configurado en el application pool de IIS por lo tanto
el conexion pool se sigue utilizando eficientemente.

Microsoft antes vendia SP con su famoso modelo de N capas por 2
motivos principales, el pool de conexiones como vos mencionaste y para
tener un mayor control de seguridad. Lo unico que le veo sentido en
esto es por ahi seguridad, pero el hecho de usar SP te limita mucho a
la hora de programar la aplicacion, no tenes buen soporte de ORM y
perdes todo el dinamismo que un ORM podria brindar. Con el tema de
performance, existen varios profiler tools que ya funcionan a nivel
ORM (ya sea Entitity Framework, NH o lo que venga), analizan los
queries que se generan a nivel codigo y detectan problemas o cuellos
de botella.

Saludos

On Jun 14, 9:30 am, Carlos Peix <carlos.p...@gmail.com> wrote:
> Hola Leo
>

> 2011/6/13 Leonardo Micheloni <leonardogabrielmichel...@gmail.com>

>
> > entonces si quiero auditar que las consultas aprovechen los índices +
> > limitar permisos de ejecución por identidad, es conveniente usar SPs?
>
> Lo de auditar el uso de indices, desconozco. De todas maneras quiero aclarar
> que mi opcion default no es usar IQueryable y linq por toda la aplicacion.
> Yo prefiero hacer una suerte de "stored procedures" en codigo usando queries
> encapsulados (ya sea en repositorios o en EQO). Ambos se pueden probar y
> verificar uso de indices.
>
> Creo que hay que tomar en cuenta el entorno. No es lo mismo si tenes
> clientes desktop que se conectan a tu BD directamente que si tenes una
> aplicacion web o te conectas mediante una capa de servicios hosteada en WCF.
>
> El problema de acceder directo con la identidad del usuario en aplicaciones
> Web es la escalabilidad, los pools de conexiones casi no sirven en ese
> escenario.
>
> En una aplicacion desktop tampoco pero es esperable tener menos cantidad de
> conexiones a la base de datos.
>
> ----------------------------------
> Carlos Peix
>
>
>

> > 2011/6/13 Walter Poch <walter.p...@gmail.com>

>
> >> Buenas a todos,
>
> >> Creo que como ya se ha planteado que los SP, mejoran la performance pero
> >> indirectamente:
>

> >>    - son más fáciles de auditar y detectar cuellos de botella
> >>    - generalmente pasan revisiones de más de una persona (aka DBA)

>
> >> Nosotros los usamos por el tema de DBA, y seguridad. Facilitan un manejo
> >> bastante granular de permisos.
>
> >> Todo esto no es exclusivo de los SPs, pero veo como que por default los
> >> SPs llevan a ese modo de trabajo; en cambio por lo menos lo que yo conozco
> >> usando LINQ muchas veces ni se revisan los execution plans.
>
> >> Saludos,
>

> >> walter.p...@gmail.com

>
> >> --
> >> Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano"
> >> de Grupos de Google.
> >> Para publicar una entrada en este grupo, envía un correo electrónico a
> >> altnet-...@googlegroups.com.
> >> Para anular tu suscripción a este grupo, envía un correo electrónico a
> >> altnet-hispan...@googlegroups.com
> >> Para tener acceso a más opciones, visita el grupo en
> >>http://groups.google.com/group/altnet-hispano?hl=es.
>
> >  --
> > Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano"
> > de Grupos de Google.
> > Para publicar una entrada en este grupo, envía un correo electrónico a
> > altnet-...@googlegroups.com.
> > Para anular tu suscripción a este grupo, envía un correo electrónico a
> > altnet-hispan...@googlegroups.com
> > Para tener acceso a más opciones, visita el grupo en

> >http://groups.google.com/group/altnet-hispano?hl=es.- Hide quoted text -
>
> - Show quoted text -

[Leonardo Micheloni]

Si, es lo que había entendido, es uno de esos casos en que al no serme útil en mi escenario actual, no me cierra del todo, gracias!

2011/6/14 Carlos Peix <carlo...@gmail.com>

--

[Esteban Grinberg]

"entonces si quiero auditar que las consultas aprovechen los índices + limitar permisos de ejecución por identidad, es conveniente usar SPs?"

No necesitas apelar a los SP para verificar si los indices se están utilizando correctamente. Podes usar el profiler y capturar el plan de ejecución de cada query

"no tenes buen soporte de ORM y perdes todo el dinamismo que un ORM podria brindar"

Esto es relativo, depende del tipo de aplicación. Algunas características propias de cada motor de las bases de datos, no están implementadas en un ORM. Lo cual o dejamos de utilizarlas o tenemos que inventar hacks para hacerlo compatible con un ORM o no usamos ORM...

2011/6/14 cibrax <cib...@gmail.com>

[Leonardo Micheloni]

"entonces si quiero auditar que las consultas aprovechen los índices + limitar permisos de ejecución por identidad, es conveniente usar SPs?"

No necesitas apelar a los SP para verificar si los indices se están utilizando correctamente. Podes usar el profiler y capturar el plan de ejecución de cada query

seguro, la pregunta es si en caso que no usen los índices que me interesa qué puedo hacer, y si aquello que puedo hacer no termina siendo trabajo extra

2011/6/14 Esteban Grinberg <esteban....@gmail.com>

[Carlos Peix]

Hola Pablo,

2011/6/14 cibrax <cib...@gmail.com>

"El problema de acceder directo con la identidad del usuario en
aplicaciones
Web es la escalabilidad, los pools de conexiones casi no sirven en
ese
escenario. "

Carlos, este escenario ya no es demasiado cierto en estos tiempos.
ASP.NET por ejemplo no impersona a los usuarios por default y es muy
raro el caso en que necesites realmente impersonar, todo corre siempre
bajo el usuario configurado en el application pool de IIS por lo tanto
el conexion pool se sigue utilizando eficientemente.

Quise decir eso, probablemente un poco confuso. Si haces autenticacion por la identidad de usuario detras del browser, por seguridad integrada, de manera que las credenciales del usuario llegan a la BD y ahi definen los permisos, me parece que perdes el connection pool. En cambio, si trabajas accediendo a la base de datos mendiante las credenciales del proceso en IIS (manejando la autorizacion de otra manera) si dispones del pool.

Esto fue lo que quise decir pero aun puedo estar errado. Me equivoco?

El el resto del mail, estoy de acuerdo.

----------------------------------
Carlos Peix

[Carlos Peix]

2011/6/14 Leonardo Micheloni <leonardogabr...@gmail.com>

"entonces si quiero auditar que las consultas aprovechen los índices + limitar permisos de ejecución por identidad, es conveniente usar SPs?"

No necesitas apelar a los SP para verificar si los indices se están utilizando correctamente. Podes usar el profiler y capturar el plan de ejecución de cada query

seguro, la pregunta es si en caso que no usen los índices que me interesa qué puedo hacer, y si aquello que puedo hacer no termina siendo trabajo extra

Lo mismo que haces dentro del SP, modificar la estructura del query o "hintearlo" (disculpen el neologismo). Siempre dentro del EQO. Puede ser con HQL en NH, con SQL en NH o con SQL y un datareader :-p, etc.

----------------------------------
Carlos Peix

[Esteban Grinberg]

Si queres que usen los indices que vos necesitas, tenes 3 opciones:

1) Hacer las cosas bien para que el SQL Server detecte que hay que usar esos indices :)

2) Ponerle un hint para forzar el uso del indice

3) Usar un custom execution plan, para decirle al SQL Server como deseas que se ejecute la consulta.

Cualquiera de estas 3 opciones, usar SP o no usarlo, es lo mismo desde lo técnico. La ventaja para mi (ademas del tema de la seguridad), como ya dije antes, es que es mucho mas productivo ir "jugando" con una consulta para lograr el rendimiento deseado, cuando la tenes encapsulada en un SP, que cuando la tenes en código...

2011/6/14 Leonardo Micheloni <leonardogabr...@gmail.com>

[cibrax]

Si esta bien, la unica manera que lleguen las credenciales a la base
de datos es si configuraste tu application de ASP.NET para que
impersone al usuario logueado (Identity impersonate=true) y que la
autenticacion sea por seguridad integrada. Con windows authentication
o integrada solo sin configurar impersonation, IIS nunca impersona el
working process con el usuario logueado y por ende las credenciales no
llegan a la base de datos.

Saludos

[Leonardo Micheloni]

Si Esteban, eso mismo es lo que quise decir, a veces soy demasíado ahorrativo con las palabras :)

2011/6/14 Esteban Grinberg <esteban....@gmail.com>

[Carlos Peix]

2011/6/14 cibrax <cib...@gmail.com>

Si esta bien, la unica manera que lleguen las credenciales a la base
de datos es si configuraste tu application de ASP.NET para que
impersone al usuario logueado (Identity impersonate=true) y que la
autenticacion sea por seguridad integrada. Con windows authentication
o integrada solo sin configurar impersonation, IIS nunca impersona el
working process con el usuario logueado y por ende las credenciales no
llegan a la base de datos.

Correcto, pero para autorizar sobre los objetos en la base de datos a cada usuario (o grupo) lo unico que te queda es impersonar, tal como decis. Estoy de acuerdo en que es una tecnica que no se usa mas.

----------------------------------
Carlos Peix

[Andres Aiello]

Sobre el tema de indices lo mas probable es que utilizando o no stored
procedures, procedas de la misma manera. La traza que vas a analizar
va a ser a nivel de statment asi que es lo mismo si viene o no de un
sp (siempre bajo la hipotesis 1sp=1consulta). Los indices que se van a
utilizar los vas a ir viendo noayudando al sql, sino haciendo bien las
consultas y dejando q el sql decida. El sql es bueno en eso y en lo
personal soy partidario de no utilizar CASI nunca hints.
La flexibilidad de tenerlo en sp es mucha visto que si quiero puedo
hacer q un stored en particular se ejcute con permisos diferentes a
los del usuario pudiendo de esta manera hacer tareas que de otra forma
deberia darle mas privilegios de los deseados.

On 14 jun, 15:59, Esteban Grinberg <esteban.grinb...@gmail.com> wrote:
> Si queres que usen los indices que vos necesitas, tenes 3 opciones:
> 1) Hacer las cosas bien para que el SQL Server detecte que hay que usar esos
> indices :)
> 2) Ponerle un hint para forzar el uso del indice
> 3) Usar un custom execution plan, para decirle al SQL Server como deseas que
> se ejecute la consulta.
>
> Cualquiera de estas 3 opciones, usar SP o no usarlo, es lo mismo desde
> lo técnico. La ventaja para mi (ademas del tema de la seguridad), como ya
> dije antes, es que es mucho mas productivo ir "jugando" con una consulta
> para lograr el rendimiento deseado, cuando la tenes encapsulada en un SP,
> que cuando la tenes en código...
>

> 2011/6/14 Leonardo Micheloni <leonardogabrielmichel...@gmail.com>
>
> > *"entonces si quiero auditar que las consultas aprovechen los índices +
> > limitar permisos de ejecución por identidad, es conveniente usar SPs?"*

> > No necesitas apelar a los SP para verificar si los indices se están
> > utilizando correctamente. Podes usar el profiler y capturar el plan de
> > ejecución de cada query
> > seguro, la pregunta es si en caso que no usen los índices que me interesa
> > qué puedo hacer, y si aquello que puedo hacer no termina siendo trabajo
> > extra
>

> > 2011/6/14 Esteban Grinberg <esteban.grinb...@gmail.com>
>
> >> *"entonces si quiero auditar que las consultas aprovechen los índices +
> >> limitar permisos de ejecución por identidad, es conveniente usar SPs?"*

> >>  No necesitas apelar a los SP para verificar si los indices
> >> se están utilizando correctamente. Podes usar el profiler y capturar el plan
> >> de ejecución de cada query
>

> >> *"no tenes buen soporte de ORM y perdes todo el dinamismo que un ORM
> >> podria brindar"*

> ...
>
> leer más »

[juan ladetto]

Mucho se escribió sobre SP y queries preparados y la verdad todos los comentarios más que jugosos.

En uno de mis trabajos (lanacion.com) teníamos un ambiente donde los periodistas producían noticias separados por rangos (dataEntry, redactor, editor).

Las conexiones estaban impersonalizadas por cada rol de cada usuario, pero queríamos que cada usuario pueda manipular determinada información de las tablas podíamos haber dado permisos sobre las tablas compeltas pero en vez de eso hicimos que dependiendo del usuario pueda acceder a los datos y manipularlos mediante SP únicamente afectando a los campos que nosotros queríamos que afectaran.

Además pusimos 2 niveles de usuarios (intranet y web) (uno para los usuarios internos y otros para los usuarios de la web). por como teníamos la app armada, era imposible que un usuario web pueda acceder a los privilegios de los de la intranet y por ende si nos hackeaban únicamente podrían acceder a determinada información y no manipular otras...

My 2 cents...
Juan

[Gustavo]

Este ejemplo me parecio muy interesante y valioso, pero me genera una duda, que tan difícil es lograr el mismo nivel de seguridad utilizando un orm/dal cualquiera con prevención de sql injection?

El tema de autorización, lo mas probable es q la UI requiera de conocer el rol, por lo que algún store con esa información debes tener. O sea que la autorización podría ser a nivel capa de servicio, o no?

Quizás hayan mas tipos de ataques, o algo así.

Saludos,

Gus

Sent from my iPad

--

[José F. Romaniello]

Pero claro Gus!... En lo unico que han probado ser buenas las bases de
datos relacionales es guardar datos (y hasta por ahí nomas..)

Generalmente la autorzaciòn es a nivel de casos de usos, no de datos
ailados en un modelo (relacional) que rara vez tiene significado para
el usuario.

Me parecería hasta mas razonable manejar autorización a nivel de
documentos (mongodb etc..) que de tablas o sps.

Otro ejemplo absurdo es oracle que te deja definir pantallas dentro de
la bd en plsql..

El 19/06/11, Gustavo <mach...@gmail.com> escribió:

--
Enviado desde mi dispositivo móvil

[Carlos Peix]

Hola Gustavo,

Dependiendo de la arquitectura de la aplicacion, el argumento de la seguridad tiene mas o menos peso. En una aplicacion Web, no hay mucha ventaja puesto que la base de datos esta protegida detras de la aplicacion (si la aplicacion esta bien hecha).

Distinto es el caso de las aplicaciones desktop (condicion 1) que se conectan directamente a la base de datos (condicion 2). Si se dan estas dos condiciones, la base de datos esta directamente expuesta a las conexiones, por lo tanto, debe protegerse. La manera mas razonable reducir (solo reducir, no eliminar) la superficie expuesta con stored procedures para operaciones controladas sin dar acceso a las tablas.

Creo que fue este ultimo escenario el que mencionaron los que justificaron los SP por cuestiones de seguridad y yo estoy de acuerdo con ellos. Tambien con Jose en que no es muy efectivo, pero es lo unico que puede hacerse.

----------------------------------
Carlos Peix

2011/6/19 Gustavo <mach...@gmail.com>

[Esteban Grinberg]

En lo unico que han probado ser buenas las bases de
datos relacionales es guardar datos (y hasta por ahí nomas..)

Eh!! Porque tanta bronca con las bases de datos relacionales?? Hay veces que hacen maravillas!

2011/6/19 José F. Romaniello <jfroma...@gmail.com>

[Gustavo]

Estamos hablando de apps de escritorio con acceso directo a la bd. No se que tan común sea eso, pero con un sencillo webservice te ahorras el acceso a la db directo y hasta centralizas la lógica en la volteada.

O sea que esta ventaja en particular de las dbs están restringidas a un grupo de apps bastante pequeño de dudosa arquitectura. Me quedo mas tranquilo entonces :)

Gus

Sent from my iPad

[José F. Romaniello]

No, en eso disiento.. No me cierra distribuir una aplicación físicamente solo para proteger la base de datos. Mucho overhead en relación a lo poco que se gana.

Por decir, en ese escenario ofuscar los datos de conexión a la base de datos me parece hasta más razonable.

Tal vez si me das a elegir solamente entre escribir una "capa de store procedures" vs "distribuir fisicamente la aplicación" (webservices/soa/rest/etc) me quedo con lo segundo. 

[Edgar Ramos]

Gustavo, me he confundido un poco en esto
---

apps de escritorio con acceso directo a la bd

---

Cuentan apps en este grupo, si de por medio utilizas un ORM, con un capa de acceso a datos, DAO's, repositorios, para CRUD ?



Saludos
Edgar

[Angel Java Lopez]

Con respecto a:

En lo unico que han probado ser buenas las bases de
datos relacionales es guardar datos (y hasta por ahí nomas..)

Me cito a mi mismo ;-):

¿En qué brillan las bases de datos relacionales? Una: en el manejo de conjuntos de datos. Nada procedural o de objetos mejora un simple

update articulos set precio = precio* 1.10

....

El otro punto donde brillan las bases de datos (relacionales o no) es en el manejo de la concurrencia:....

Fuente:
http://msmvps.com/blogs/lopez/archive/2010/08/08/look-ma-no-database.aspx

Nos leemos!

Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

2011/6/20 Esteban Grinberg <esteban....@gmail.com>

[Leonardo Micheloni]

Claro José, la autorización se hace por caso de uso, un concepto de
objetos, otro lugar donde complica la impledancia relacional-objetos

Si la seguridad de los datos que se pueden ver (sean o no dependientes
del caso de uso) se pone únicamente en la lógica de negocios (no digo
que esté bien o mal) y le quitamos esa responsabilidad a la DB también
empezamos a llegar al modelo en que la DB tampoco debería validar los
tipos de datos (cosa con la que en algunas épocas estoy de acuerdo y
otras no) yo he intercambiado opiniones sobre esto con gente de DB
sobre cuál es la responsabilidad de la DB, podemos cuestionar todo,
los check, las foreing keys, los tipos de datos, si queremos mantener
todo de una manera homogenia y controlada (control de versiones, etc)
me parece mucho mejor el enfoque "la DB es una bolsa donde simplemente
persisto los datos" porque como dijo Angel si la electricidad nunca se
cortase podríamos evitar las DB....

[José F. Romaniello]

El 20 de junio de 2011 13:09, Leonardo Micheloni <leonardogabr...@gmail.com> escribió:

Si la seguridad de los datos que se pueden ver (sean o no dependientes
del caso de uso) se pone únicamente en la lógica de negocios (no digo
que esté bien o mal) y le quitamos esa responsabilidad a la DB también
empezamos a llegar al modelo en que la DB tampoco debería validar los
tipos de datos

A mi me parece que "tipos de datos" es un concepto más cercano a persistir datos... que al tema de autorización pero admito que es subjetivo. 

Dejando eso de lado, hoy en día la mayoría de las bases de datos no relacionales que están en auge tienen un modelo de datos schema-less (o schema-free) y te aseguro que no vas a escuchar a mucha gente que esta trabajando con mongodb renegar de eso. Por lo general el que probo no volvió :P

[Esteban Grinberg]

Leonardo, en el mundo corporativo por lo menos, yo creo que el enfoque de "la DB es una bolsa donde simplemente persisto los datos" algunos lo sostienen simplemente porque no usan ese enfoque.

Seria incontable la cantidad de errores, bugs y problemas que tendríamos y se nos complicaría encontrar si nuestras bases de datos fuesen simplemente archivos "bobos" para almacenar información.

Ni hablar que en un mundo corporativo, las bases de datos (por lo menos, las importantes) no suelen ser de uso exclusivo por una sola aplicación.

No me parece complicar el código de una aplicación y perder performance, simplemente porque quiero ganar homogeneidad.

2011/6/20 Leonardo Micheloni <leonardogabr...@gmail.com>

[Gustavo]

No creo que se gane poco, sino SOA no existiría. Tampoco digo que sea necesario cambiar una aplicación y hacerla distribuida para poder proteger la base de datos. Simplemente cuestiono que el hecho de que se acceda directamente ya es un poco dudoso, y algo que yo trataría de evitar. Por lo que lo que el beneficio de autorización en las bases de datos me suena a algo muy valioso en muy pocos casos.

Claro que si ya tenes una app que accede directo a la db puede ser menos costoso manejar la autorización desde la base de datos.

Saludos

Sent from my iPad

[Gustavo]

Edgar, si cuentan.

Sent from my iPad

[Leonardo Micheloni]

y qué me decís de las claves foráneas, los checks, y esas cosas? no es
lógica de negocios decir que no puede existir un detalle-factura sin
una cabecera-factura?

[Edgar Ramos]

Gustavo

Por lo que entiendo, hay algun esquema en mi arquitectura que no estoy tomando en cuenta.
Por otro lado, desde la app, cada pantalla (Casos de Uso), es utilizada unicamente por la persona con el rol especifico.
esto cuenta en algo ?, que mas haría falta de acuerdo a tu criterio ?


Saludos
Edgar

[David Lay]

Estimados, he estado siguiendo el hilo con mucha atención y me gustaría darme el tiempo de contarles mi experiencia al respecto.

Trabajo en una empresa en donde hacemos aplicaciones desktop a medida para un cliente cuyas bases de datos han pasado desde archivos planos en foxpro o delphi hasta hoy en día sql server 2005. Debido a las migraciones que ha sufrido y la falta de oficio de quienes fueron realizandolas, el esquema de datos es un asco de campos null, tablas sueltas, ausencia casi completa de pks, fks e indices.

Hace dos años y medio estamos en un nuevo proceso de actualización completo que incluye aplicaciones en .net y la creación de un modelo de datos acorde con los tiempos y a las necesidades del negocio.

Para esto tomamos la decisión de usar los procedimientos almacenados como una capa de abstracción y esto nos ha permitido llevar un desarrollo iterativo tanto del modelo como de las aplicaciones, con migraciones de bajo riesgo.

Para facilitar un desarrollo de estas características, desarrollamos una librería de acceso a datos que utiliza solamente procedimientos almacenados y es capaz de leer objetos, pasar sus propiedades como parámetros y los resultados pasarlos a objeto con un mapeo columna-propiedad, todo basado en nomenclaturas.

Pareciera que mis circunstancias son especiales según lo que leo en la lista ya que la mayoría parece estar trabajando en bases bien modeladas o en aplicaciones web relativamente nuevas, pero estoy seguro que esta realidad de utilizar procedimientos como abstracción es muy usada y conocida en los proyectos de mantención y migración.

No digo que sea un buen uso de los sp, ni digo que sea para lo único que sirven, pero sin duda que es uno de los usos que yo personalmente he visto más.

David Lay M

Por favor disculpe faltas de ortografía o si el correo ha resultado muy brebe ya que he repondido desde mi movil.

---

From: Edgar Ramos <eramo...@gmail.com>

Sender: altnet-...@googlegroups.com

Date: Mon, 20 Jun 2011 15:39:41 -0500

To: <altnet-...@googlegroups.com>

ReplyTo: altnet-...@googlegroups.com

Subject: Re: [altnet-hispano] Re: Stored procedures o queries?

[Esteban Grinberg]

Los checks son como trigger pero con un scope mas pequeño. La verdad nunca en vida los utilice, ni he visto aplicaciones que los usen.

Los FK son un mundo aparte. Yo no diria que una FK es una logica de negocios, sino mas bien, una relacion entre los datos. Pero eso es una cuestion mas abstracta.

La realidad es que hasta ahora jamas he encontrado una desventaja al uso de FK y si muchas ventajas. Las constraints en una BD yo la veo como la ultima instancia de validacion posible y mucho menos susceptible a errores del programador. 
MongoDB y todo el mundo NoSQL, en el ambiente corporativo (salvo situaciones especiales que siempre las hay) no le veo ventaja contra una relacional.

2011/6/20 Leonardo Micheloni <leonardogabr...@gmail.com>

[Leonardo Micheloni]

"Las constraints en una BD yo la veo como la ultima instancia de
validacion posible y mucho menos susceptible a errores del
programador. "

con el mismo criterio se podrían poner las validaciones de negocios en la DB.
Hablando de validaciones de tipos en la DB, un email sería un tipo de
datos? al menos sqlserver no lo soporta como tipo (si bien ser puede
hacer un tipo custom con .net y generarlo)

[David Lay]

La responsabilidad de una db relacional no solo es almacenar y proveer rápido/conveniente acceso a los datos, sino que además asegurar su integridad. Esto significa establecer reglas de llaves foráneas y tipos de datos.

Las relaciones entre objetos y reglas de negocio entre ellos (interacciones) son generalmente una elaboración mayor de estas reglas.
Pero la base de datos relacional no es un simple almacenamiento. La base de datos relacional de una empresa muchas veces trasciende tecnologías, sistemas e incluso equipos de desarrollo, por lo cual no esta para nada demás la definición de estas reglas (mínimas) de integridad.

Los triggers y procedimientos que efectúan lógica de negocio son una bestia completamente distinta y a mi parecer son muy contraproducentes.

David Lay M

Por favor disculpe faltas de ortografía o si el correo ha resultado muy brebe ya que he repondido desde mi movil.

-----Original Message-----
From: Leonardo Micheloni <leonardogabr...@gmail.com>
Sender: altnet-...@googlegroups.com

[Esteban Grinberg]

Leonardo, yo no me asusto de validar el negocio en la DB. Hay gente que si. Cuestion de gustos y costumbres.

También hay que saber diferenciar que no todas las validaciones son lo mismo. No es lo mismo una validación de tipo datos, que una validación sobre rango de fechas que una validación de negocio.

Un email es un tipo de dato con lógica agregada. Las veces intente crear tipos de datos customizados en las BD, luego me di cuenta, que son complicados de mantener.

Pero invirtamos la pregunta, que desventajas te aportan las contraints y las restricciones de dato en el diseño de tu arquitectura?

Ojo que también depende del ámbito, una feature puede ser importante o no. En general, en un sistema web, probablemente una base de datos "shema less" tenga mas aceptación, porque son bases mas aisladas con otros objetivos.

En una aplicación empresarial, donde las bases de datos suelen tener múltiples fuentes de entrada y salida en distintas aplicaciones o ETLs y la calidad de los datos es mas importante, no tener una estructura mínima de validación de "bajo nivel", seria inaceptable.

Siempre digo que los programadores tienen que pensar que no son los únicos usuarios de una BD.

2011/6/20 Leonardo Micheloni <leonardogabr...@gmail.com>

[Carlos Peix]

Hola a todos,

Yo opino que, cuando usamos una base de datos relacional, debemos comprender que trabajamos con un modelo de datos (relacional).

Por ende, la base de datos es un buen lugar para verificar validez del modelo de datos: constraints, foreign keys, primary keys, *algunas* unique keys (si hacen al modelo de datos), nulls, no nulls y tipos de datos (todos los posibles, incluso email si no es complejo). Estos constraints puede imponerse con cualquier herramienta, incluso triggers o stored procedures, aunque suele bastarme con la definicion estructural.

Lo que no me gusta hacer (y esto es mas personal) es colocar logica que no corresponda al modelo de datos. Este tipo de logica suele encontrarse en stored procedures o triggers. Entonces el problema (en mi caso), no es la herramienta que se use sino para que se usa.

El problema que encuentro con la logica de negocio en la base de datos (en SPs, triggers o funciones) es que cuando mas coloquemos, mas trabajo nos cuesta mantenerla sincronizada con la logica que, por fuerza, tambien debe estar en la aplicacion. Mi enfoque es solo colocar logica que hace a la integridad del modelo de datos. El modelo de negocios lo mantengo en el codigo.

A los que nos gustan los ORMs, ademas, nos complican un poco los stored procedures pero tambien los usamos en ciertos casos extremos.

Abrazo

----------------------------------
Carlos Peix

2011/6/20 Leonardo Micheloni <leonardogabr...@gmail.com>

[daniel...@gmail.com]

El tema seguridad excede la aplicacion.
Muchas veces una db es accedida por mas. de una aplicacion, los store procedures, en cuanto a seguridad se refiere, fortalecen en ese aspecto porque solo se da acceso a las tablas de la db pasando por ellos.
Nadie entonces que conozca un login de la base de datos, por una falla de seguridad o no, podra acceder a las tablas o vistas.
Olvidense de la aplic que ustedes desarrollan, viene pepe con un access, arma una ODBC, conoce un login valido, adjunta cuanta tabla quiere.
Trabajo en un banco y en su momento los SP fueron la herramienta para cumplir con las normas de seguridad que impone el banco central de la republca argentina.
Hoy ya no se usan y se impulsa no hacerlo, pero se accede a las db mediante un proxy que valida que aplic se conecta.
Solo cuento esto para mostrar que cuando se habla de seg y sp no siempre hablamos de estos en el contexto de nuestra aplicacion.
Por ultimo creo que hay cosas que se resuelven con aplicaciones datacentricas y no oop. Si no es asi me gusyaria ver un datawarehouse basado en objetos.... :)
Solo mi mirada sobre tema.

Todo sirve para algo, pero, nada sirve para todo...
( Use nada decia Mafalda, un personaje quino )
Los que hacemos OOP parece algunas veces que creemos que sirbve para todo...

Daniel

Enviado desde mi BlackBerry de Movistar (http://www.movistar.com.ar)

---

From: Carlos Peix <carlo...@gmail.com>

Sender: altnet-...@googlegroups.com

Date: Mon, 20 Jun 2011 20:38:04 -0300

To: <altnet-...@googlegroups.com>

ReplyTo: altnet-...@googlegroups.com

Subject: Re: [altnet-hispano] Stored procedures o queries?

[Yesenia María Zapata Pulido]

Hola,

Estaba buscando informacion de un caso poco comun o por lo menos es la primera vez q tengo este incidente, aun tengo la inquietud tengo un servidor

Y al momento de ejecutar un sp tarda mas de 4 horas al invocar el job sin embargo como consulta no tarda ni un minuto, saben si existe algun parametro que debe configurarse que mejore los rendimientoes de los sp.

Como se ve es un incidente del año pasado pero me he quedado con la inquietud porque pasa esta anomalia.

Y a como pueden ver no da timeout se ejecuta pero con demasiado tiempo

A alguno le habra dado algo similar?

[Gabriel Osorio]

Hola. Me pasó algo similar con MySQL. En mi caso la consulta nunca se realizaba debido a un exceso de anidación de subconsultas.

Se supone que los procedimientos almacenados son compilados, de manera que son más rápidos que los queries que deben ser interpretados. Por lo tanto, al parecer el problema (también) está relacionado con el optimizador del plan de ejecución de la consulta; que resulta ser diferente en ambos casos.

Aquí entro a suponer (aspiro a que alguien corrobore o corrija) sobre tu caso. Si el plan de ejecución se guarda junto con el SP, entonces puede ser producto de una versión más vieja del optimizador. También puede ser que el optimizador use diferentes rutinas para resolver la consulta cuando se trata de un SP o de un Query.

Mi conclusión es que, independientemente de ambos resultados, la consulta (query o SP) debe ser rediseñada pues está en el límite de eficiencia de la DB.

--

Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispano+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-hispano@googlegroups.com.
Visita este grupo en https://groups.google.com/group/altnet-hispano.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Yesenia María Zapata Pulido]

Gabriel Osorio,

Gracias por la respuesta y evalue los planes de ejecucion y a como mencionas creo que es problemas del servidor sin embargo en cuanto a tiempos la ejecucion del sp de 4 horas versus segundos es abismal y si hice un par de consultas para ver el estado de la memoria y curiosamente el consumo esta en la default y la virtual casi no se ocupa para nada mas bien por no decir que nada por eso tenia la duda si se podria configurar algo para que los sp pudieran ejecutarse mejor.

Poste por aca la respuesta porque en googlegroups no soy tan recurrente de hacer pregunas.

Y gracias por tu respuesta.

Saludos.

[juan ladetto]

Las pruebas fueron en 2 ambientes distintos? El query plan debería darte información dónde se va el consumo.

Acordarse q equipos distintos pueden dar planes distintos x temas de índices, volúmenes de info guardada, etc. Nosotros en algún momento tuvimos q decirle a algunos sps que hagan recompile x cada ejecución porque el query plan q armaba algunas veces no era el más performante.

Otra tuvimos q mejorar los subqueries o forzar un índice determinado.

Si puedo ayudar a leer queryplan avísame x privado.

Saludos

Juan

--

[Carlos Admirador]

Un caso interesante:

https://geeks.ms/windowsplatform/2016/07/20/por-que-unos-cuantos-millones-de-tuplas-pueden-reventar-tu-ultra-flamante-optimizada-parametrizada-y-vitaminada-consulta-en-linq-to-entities-o-tsql/

Procedimiento Almacenado lento, pero su Consulta es rápida ¿Por qué ocurre? ¿Por el Plan de Ejecución? ¿Por las Estadísticas? ¿Es Parameter Sniffing?

http://www.guillesql.es/Articulos/Procedimiento_Almacenado_Lento_Consulta_Rapida_Plan_Ejecucion_Parameter_Sniffing.aspx

https://grimpidev.wordpress.com/2009/01/23/parameter-sniffing

En general, utilizar SPs o no en el desarrollo (o en procesos jobs). 

El sitio StackOverflow dejó utiliza procedimientos almacenados, utilizando su micro ORM Dapper. Imagino que su "SQL is pretty simple"

https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/

Our usage of SQL is pretty simple. Simple is fast. Though some queries can be crazy, our interaction with SQL itself is fairly vanilla. We have some legacy Linq2Sql, but all new development is using Dapper, our open source Micro-ORM using POCOs. Let me put this another way: Stack Overflow has only 1 stored procedure in the database and I intend to move that last vestige into code.

De Marcos Mellibovsky:

Para saber la causa seria bueno pedir el plan de ejecucion del SP y ver en los momentos en que esta lerdo si no hay demoras por bloqueos o por carga del sql.

Te paso un query que te muestra lo que esta ejecutando el sql en el momento con sus algunos datos como tipo de query, quien la esta bloqueando, CPU, Reads, Writes, Tipo de Espera, que recurso espera y hasta el texto del query

SELECT req.session_id,  start_time, req.status, command, blocking_session_id, percent_complete

, estimated_completion_time, req.cpu_time, req.total_elapsed_time, req.reads, req.writes, req.logical_reads

, wait_type, wait_time, last_wait_type, wait_resource, request_id, req.database_id, db.NAME AS base, USER_ID

, req.transaction_isolation_level, req.row_count, open_transaction_count, open_resultset_count, ses.HOST_NAME, ses.program_name, ses.login_name, ses.last_request_start_time

, query.text tsql

 FROM sys.dm_exec_requests req LEFT JOIN sys.databases db ON req.database_id = db.database_id

 LEFT JOIN sys.dm_exec_sessions ses ON req.session_id = ses.session_id

CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) AS query

WHERE req.session_id > 40 AND req.session_id <> @@SPID

Recompilar sirve si el problema se debe a que las tablas involucradas hay cambiado mucho en cuanto a cantidad de registros o a los datos de las columnas indexadas, lo cual hace que la estadisticas queden desactualizadas.

El miércoles, 10 de enero de 2018, 19:05:25 (UTC+1), juan escribió:

Las pruebas fueron en 2 ambientes distintos? El query plan debería darte información dónde se va el consumo.

Acordarse q equipos distintos pueden dar planes distintos x temas de índices, volúmenes de info guardada, etc. Nosotros en algún momento tuvimos q decirle a algunos sps que hagan recompile x cada ejecución porque el query plan q armaba algunas veces no era el más performante.

Otra tuvimos q mejorar los subqueries o forzar un índice determinado.

Si puedo ayudar a leer queryplan avísame x privado.

Saludos

Juan

El 10 ene. 2018 2:47 p. m., "Yesenia María Zapata Pulido" <zapatapul...@gmail.com> escribió:

Gabriel Osorio,

Gracias por la respuesta y evalue los planes de ejecucion y a como mencionas creo que es problemas del servidor sin embargo en cuanto a tiempos la ejecucion del sp de 4 horas versus segundos es abismal y si hice un par de consultas para ver el estado de la memoria y curiosamente el consumo esta en la default y la virtual casi no se ocupa para nada mas bien por no decir que nada por eso tenia la duda si se podria configurar algo para que los sp pudieran ejecutarse mejor.

Poste por aca la respuesta porque en googlegroups no soy tan recurrente de hacer pregunas.

Y gracias por tu respuesta.

Saludos.

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.

[Yesenia María Zapata Pulido]

Gracias por las respuestas, ahora si me queda claro todo.

Saludos.

[Carlos Admirador]

Yesenia, pudiste solucionarlo?

[Yesenia María Zapata Pulido]

Buenas tardes de hecho que si pude solucionar y entender la diferencia en el caso. Sin embargo para los sp con los que tuve problemas con el tiempo me ayudo mucho agregar OPTION (OPTIMIZE FOR

UNKNOWN);

mas que la optimización de recompilar.

Gracias a todos por estos comentarios.

Una pregunta que grupos puedo utilizar para foros de programaicon en visual .net

Saludos.