SQL Server - Carga de consultas en una BD

 
Vista:
sin imagen de perfil

Carga de consultas en una BD

Publicado por Daniel (8 intervenciones) el 17/10/2018 14:39:42
Buenos días, una duda, de que manera cargamos menos el trabajo de la BD? si envío la consulta SQL desde un formulario VisualBasic o si armo un procedimiento almacenado en la misma BD?.
Espero se haya entendido la pregunta.
Muchas gracias.
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
Imágen de perfil de Isaias
Val: 3.250
Oro
Ha mantenido su posición en SQL Server (en relación al último mes)
Gráfica de SQL Server

Carga de consultas en una BD

Publicado por Isaias (4558 intervenciones) el 17/10/2018 17:30:14
Te EXPLICASTE BIEN, no es que NO entendamos

Siempre sera mejor crear un PROCEDIMIENTO ALMACENADO a enviar T-SQL desde la capa cliente
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
sin imagen de perfil

Carga de consultas en una BD

Publicado por Daniel (8 intervenciones) el 18/10/2018 15:04:51
Ok, muchas gracias.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de Pancho
Val: 73
Ha mantenido su posición en SQL Server (en relación al último mes)
Gráfica de SQL Server

Carga de consultas en una BD

Publicado por Pancho (29 intervenciones) el 17/10/2018 18:40:08
Buen dia

Un procedimiento almacenado no siempre es la solucion magica al problema, depende de otros factores:

1) Calidad de Hardware:
==================
Aqui se determina el sistema de disco RAID, SCSI, SAN, cantidad de memoria, nucleos del procesador, etc, si el servidor es dedicado o no

2) Normalizacion de la base den datos:
==============================
Mas que critico, un mala normalizacion implica redundancia innecesaria de datos

3) El grado de optimizacion de la sentencias SQL:
======================================
En muchos casos esto es el 90% de las veces el causante del problema, aqui si hay que detenerse y examinar en detalle sobre todo del lado WHERE, el uso de SELECT * FROM es desaconsejado en grado sumo cuando hay muchos INNER JOINS. Y esto nos lleva a

4) Uso de Indices en la tablas que se requieran
====================================
Los indices son un aporte invaluable, pero por supuesto hay que se comedidos en su creacion, ya que el costo de actualizacion degrada el rendimiento de la base de datos, pero no hay nada como un bueno diseño de indice, los resultados son sorprendentes!.

5) Usar parametros comodin en vez de concatenados
==========================================
La maxima: No usar parámetros comodin en SQL es como recompilar un programa cada vez. SQL usa el comodin ? como parametros de enlace, los lenguajes modernos usan este esquema, Ruby, Java, Perl, VBA, etc, Cuidado con los ORM sobre todo en Ruby, sentencias como estas 'SELECT* FROM tabla WHERE id = #{my_id}' engañan al novato y en realidad no estas optimizando nada.

6) Afinacion del Servidor de la BD
==========================
La piedra angular, ya este nivel es para los mas veteranos si lo anterior no funciona y por lo general el DBA entra en escena aqui, Esto es a tu propia cuenta y riesgo jugar con los valores predeterminados del motor de la BD.

7) Un buen libro salva el dia!
======================
Si eres de los que no te gusta ver tutos en youtube!, te recomiendo este libro: https://sql-performance-explained.com

;-)

Saludos
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar