¿ Vista vs Procedimiento almacenado en MySQL ?

[Saúl Piña]

Buenas tardes,

Me gustaria saber cual es su diferencia,

gracias

[Fabian Enrique Blanco]

El Procedimiento se ejecuta directamente en el servidor y devuelve los datos, la vista se conecta al servidor para ejecutar la consulta sql.

[Allan Raúl Acuña]

Resumen en lo personal veo mejor el SP

Saludos cordiales.

Lic. Allan Raúl Acuña
Analista Programador
msn= allan...@hotmail.com
skype= NicEasySoft
            +(505) 8 999 8950

Managua, Nicaragua

Centroamérica

---

Date: Wed, 21 Oct 2015 10:28:46 -0700
From: fbla...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Re: ¿ Vista vs Procedimiento almacenado en MySQL ?

[Saúl Piña]

y como se ejecuta un SP creado en MySQL desde vfp?

[Ariel Octavio D'Alfeo]

Coincido con Raúl, ya que la vista es muchísimo mas lenta que un SP. la vista, primero ejecuta la consulta que tiene guardada

, y luego, sobre ese "Cursor" aplica la consulta que hicimos a la vista.

Si nuestra vista es

Create view ejemplo(
Select *from tablaConMuchisimosRegistros
)

y nuestra consulta a la vista:

Select *from tablaConMuchisimosRegistros where id=5.

lo que hara el motor es primero ejecutar Select *from tablaConMuchisimosRegistros, traera todos los registros y luego filtrara el id=5 y retornara el resultado.

con un SPnos ahorramos la primera consulta, con lo que se agiliza muchísimo

create procedure Ejemplo
  @id int
 as
  select*
   from tablaConMuchisimosRegistros
   where id= @id ;

y nuestra consulta al SP:

Exec Ejemplo(5)

Ariel D'Alfeo

Córdoba, Argentina

[Antonio Meza]

Las vistas al igual que los SP se ejecutan del lado del servidor no se confundan

Las vistas no contienen datos, por lo tanto si llamas a la vista sin filtro pues te devolverá todos los registros, si consultas la vista con filtro pues obtendrás solo los registros del filtro, seria interesante conocer en que parte del manual de Mysql dice que las vistas primero ejecutan la consulta y luego aplican el filtro suena muy ilógico.

En resumen:

• Se almacenan en el servidor con lo que el consumo de recursos y eficacia siempre serán más óptimos.
•  Una vista en mysql es una tabla virtual con una estructura que nosotros definimos pero sin datos. 
  
• En temas de seguridad siempre es mejor utilizar vistas en lugar de permitir a nadie acceder directamente a los datos, nosotros mostramos al resto de desarrolladores los datos que queremos.
• Podemos llamarlas de forma sencilla en una consulta y utilizar clausulas contra las mismas.
• Pueden haber desarrolladores con poca experiencia y con dificultades por hacer complejas consultas, podemos darles la opción de simplemente llamar a una vista para así obtener los datos.
• Una vista es un camino simple para guardar complejas consultas de selección en nuestra base de datos.
• Una diferencia entre vistas y procedimientos almacenados es que las primeras no aceptan parámetros, no siendo así con los procedimientos almacenados, que si los aceptan.
• Un procedimiento almacenado suele utilizarse cuando no es suficiente una simple consulta sql. Los procedimientos almacenados contienen variables, bucles y llamadas a otros procedimientos almacenados.

fuente:

http://uno-de-piera.com/introduccion-las-vistas-en-mysql/

saludos

Antonio Meza

[Saúl Piña]

Realicé un ejemplo y me aparece este error.. en Navicat

gracias por la sugerencia..

[Carlos Miguel FARIAS]

Saul. Estaría mal escrito el Sp. Las vistas en MySQL son rápidas si no son multicapa, o sea vistas de vistas y recién después los filtros, o vistas que usan en parte vistas y otras no.
En general es mejor una vista que un SP. Con la vista el SGBD tiene ya resuelto el plan de acceso a datos que lleva un tiempo elaborarse en un selectiva común.
Por supuesto que con tablas grandes y filtros complejos y si luego la aplicación filtra además de lo que hace la vista perder desempeñó.
Pero indicó un colega. Mejor hacer vista para consultas habituales y si se pone lento optimizar el acceso con un SP
Saludos: Miguel, La Pampa (RA)

[Allan Raúl Acuña]

Buena Antonio, gracias !

En lo personal solo he usado los SP, y les paso los parámetros y me han dado buenas respuestas.

Saludos cordiales.

Lic. Allan Raúl Acuña
Analista Programador
msn= allan...@hotmail.com
skype= NicEasySoft
            +(505) 8 999 8950

Managua, Nicaragua

Centroamérica

---

Date: Wed, 21 Oct 2015 12:28:14 -0700
From: solv...@gmail.com

To: publice...@googlegroups.com
Subject: [vfp] Re: ¿ Vista vs Procedimiento almacenado en MySQL ?

[Saúl Piña]

No sean gachos, pasenme un ejemplo... please

gracias.

[Carlos Miguel FARIAS]

Estimado Saúl

Hacer procedimientos almacenados, implica conocer un lenguaje de programación nuevo, básicamente estructurado.

Con algunos ejemplos vas a poder hacer solo lo que los ejemplos te dicen, pero de ahí a aprender todo el potencial, lejos.

Y si quieres aprender sobre SP de mysql, deberías hacer las consultas en un foro de ese SGBD.

Podes ver: http://forums.mysql.com/read.php?98,358569

https://dev.mysql.com/doc/refman/5.0/en/create-procedure.html

http://code.tutsplus.com/articles/an-introduction-to-stored-procedures-in-mysql-5--net-17843

Y el curso en ingles es con cargo. Me cargo de risa.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe hasta que quedemos derechos y no gachos (o quisiste decir guachos)

[mpulla]

Hola Antonio.

Una vista es una consulta que se representa con una tabla virtual (no es una tabla virtual) y lo que se almacena el SGDB  es su definición.

Cuando tenemos un sp el SGDB se encarga de actualizar estadísticas de los indices y datos que luego serán utilizados por el optimizador de consultas, ademas cuando se ejecuta el sp este se guarda en el cache del SGDB cuando lo ejecutas la segunda vez el SGDB lo encuentra en el cache y lo ejecuta mas rápido.

Para mi un SP tiene un mejor perform que la vista.

Saludos.

Mauricio

[Carlos Miguel FARIAS]

El desempeño de vista o SP va a ser relativo a lo que hace uno u otro.

Lo que debe analizarse es:

a) Cual de los dos logra reducir el tráfico de red (o sea, reduce los datos hacia el cliente)

b) Cual logra que el Servidor resuelva el plan de acceso a datos.

c) Cual logra reaprovechar los datos recuperados y que quedan en buffer del SGBD

d) Cual logra recuperar los datos con menos carga sobre el servidor.

Porque:

a) En definitiva, siempre el cuello de botella es la transmisión, por supuesto que ambos, en definitiva devolverían la misma cantidad de datos (para un mismo requerimiento), pero habría que ver requiere la vista o el SP para ser invocados.

b) Cuando se crea una vista, el servidor resuelve el plan de acceso a los datos, este proceso puede llevar más o menos tiempo, pero que siempre es significativo a niveles de consultas cortas/simples. Que son las mas comunes. Atención, el tiempo de resolución del plan de acceso depende mucho de la existencia o no de indices, por eso se recomiendan índices sobre las claves foráneas, sobre los campos que se usan para filtros, etc.

c) Los SGBD, ante un requerimiento de datos, cargan en memoria todos los datos posibles, y dejan en memoria los set de registros accedidos. Si una vista se usa en forma recurrente, es probable que las segundas peticiones a las mismas, ya tengan los datos disponibles, por lo que se mejora el acceso. Por eso, entre otras cosas M$ restringe la cantidad de memoria del SQL Server Express, para que ante requerimientos pesados, el limite de 1GB (creo) de uso de RAM, haga que independientemente del tamaño de la BD (que en todo caso podes fraccionar), llegue un momento que te veas forzado a migrar a las versiones pagas, porque te mata el mal desempeño.

d) Y por supuesto, si el servidor que gestiona al SGBD es muy "polenta", conviene transferir la carga de cálculo a él, pero si no, puedes transferir la carga al cliente (sobre todo si con eso no afectas a).

En definitiva, el uso de SP o vistas estará supeditado a los casos específicos de requerimiento de datos (frecuencia y modo de uso, datos estáticos o dinámicos). En cada caso, deberá sopesarse que conviene. E indiscutiblemente, no sería raro que convenga el uso combinado de ambos.

Y un factor extra para desarrolladores, si se transfiere lógica al SP, la aplicación empieza a ser SGBD dependiente (no es fácil luego migrar un SP de un SGBD a otro), lo que no es malo, si a su vez se quiere tener libertad en la elección de la herramienta en el cliente.

Para PHPeros y Pythoneros, por ejemplo, meter lógica en el SP, permite de alguna manera tener el código más protegido que tenerlo en el código normal, porque al SP, se le compila y se le puede borrar el fuente (en algunos SGBD), y el código solo es accesible a los administradores del la bd, no a cualquiera que acceda al disco.

Cada cual, en cada caso, deberá sopesar que es conveniente (o le es conveniente) aplicar.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad.

Que la Fuerza los acompañe hasta la Vista Baby o el SP

[Antonito Mt]

Debes revisar ese concepto que tienes pues pienso estas muy errado.

El motor de SQL es mas inteligente para hacer un select * sin where. La vista es solo una abstraccion pero el query equivalente se optimiza siempre que el motor lo considere.

Y no es q un SP siempre sea conveniente. Depende de la situacion. Un SP por ej no puede reemplazar una tabla en un query entre otras cosas.

[Saúl Piña]

Algun dia debo de iniciar con este tema no crees?

Como fue que ahora ustedes lo saben?

Saludos y que la fuerza de Hulk los acompañe.

[José Santos]

Buenos días,

Voy a comentar mi percepción del tema con años de experiencia y evolucionando en el.

He sido jefe de proyecto y analista funcional trabajando al lado de dba y consultores sql para DB2.

Lo primero indiza tus tablas, por las búsquedas que vas a realizar en ellas. Si no tienes un dba en tu caso pues esto es a base de pelearse e ir viendo los planes de ejecución de tus selects con tus respectivos filtros.

Una vez que tienes todo esto realizado, Consejo haz una select genérica, no vayas haciendo vistas por filtros.Ejemplo: Saco un campo distinto en una vista si paso un parametro u otro: Error Haz una vista genérica por todos los campos que necesites, luego ya utilizarás en tu codigo SELECT campos_que_necesito FROM VISTA WHERE campo = @parametro.

Las vistas se cachean una vez que la llamas por primera vez --> si quieres mas rapidez pues para eso estan los DBAs para crear filesystems, balancear ... Por eso cobran más jejeje

¿Como que no puedo pasarle parametros a una vista? Para eso están las functiones. Creas una función parametrizada.

Y te voy a dar un extra. Imagínate que haces una vista contra una tabla y esa tabla tiene foreign key contra otras. En la vista que hagas concatena tus claves foraneas para atacar con un IN en tu código

Ejemplo. Tu vista saca lo siguiente idAlumno, NombreAlumno, NotasAlumnos (esta es foreign Key tabla Notas) La vista sacará lo siguiente:

1    AAAAAA    1,4,5,6,7
2    BBBBBB     9,12,24,27

Saludos.

[Carlos Miguel FARIAS]

En mi experiencia:

a) Cualquier proceso de acceso a datos, el principal cuello de botella es lo que mandas por la red (no importa si SGBD o tablas libres).

b) Un procedimiento almacenado es bueno si reduce el trafico de red (por ejemplo, elimina comandos de ida y vuelta al cliente, por el proceso se hace en el servidor)

c) Dado un conjunto de Tablas T1, T2, T3, ... y un conjunto de vistas V1, V2, V3, ...

Si necesitas una vista VM que pueda resolverse con

   VM1 = SQLComplejo(T1, T2, T3,...)

   VM2 = SQLSimple(V1, V2, V3,...)

El tiempo de ejecucion VM1 va a ser muy inferior a VM2.

Me ha pasado que en el apuro, he resulto requerimientos usando un SQL simple sobre vistas prearmadas (que todas funcionaban bien y rápido), pero al trabajar asociadas, los tiempos de ejecución eran no aplicables y aplicando un SQL más complejo sobre las tablas, la respuesta era "sorprendentemente" más rápida (el SGBD también era MySQL).

Personalmente, considero que el SP se justifica cuando el tipo de proceso implica lógica alternativa de acceso a datos que con los SELECTs no puedas resolver, y siempre es más rápida una vista en el servidor y acceder con un simple SELECT * FROM laVista que mandar el SELECT completo desde el cliente (VFP -> SGBD, o PHP -> MySQL).

Saludos: Miguel, La Pampa

Larga Vida y Prosperidad

Que la Fuerza los acompañe y como es viernes: Hasta la Vista, Baby

[mapner]

Vista: es un comando de consulta SELECT previamente definido en la BD, sirve para: abstraer consultas complejas en llamadas simples, otro uso habitual para vistas es "disfrazar" nombres de tablas y campos en caso de usar clientes Legacy o sea aplicaciones que manipulan estructuras de BD con tablas y campos diferentes a los de la actual BD.

Procedimiento almacenado: es una porción de código en forma de procedimiento o función, por lo general en PSQL, con posibles argumentos de entrada, variables internas y campos de salida. Se suele usar para: almacenar lógica de negocio en la BD independizando esa lógica de cualquier cliente que lo invoque. El lenguaje PSQL es un poco más básico que un real lenguaje OOP, pero sirve para ciertos propósitos.

Vistas y SP sirven también para ocultar tablas y campos directos y de esa forma agregar una capa de seguridad a la BD. Los puristas opinan que tablas y campos de la BD nunca seben aer accedidos en forma directa por las aplicaciones cliente, sino es a traves de Vistas o SP.

Sobre si usar Vistas y SP aumenta el rendimiento, depende de varios factores. En principio tablas grandes con muchos registros trabajaran mejor con los índices adecuados. En cuanto a consultas, ver el "plan de ejecución" que propone el motor y analizar sus optimizaciones.

Saludos

[Antonio Meza]

Es muy sencillo confundirse, las Vistas son simples consultas, así como tu envías un SELECT * from tabla desde cualquier lenguaje el servidor analiza los indices y te da un resultado, lo mismo pasa internamente con las vistas, si la vista tiene como código SELECT * From tabla el resultado puede ser el mismo que el primer select en rendimiento, la diferencia esta que la vista ya esta dentro del servidor y se ejecutara mas rápido que la primera, pero no dejan de ser lo mismo.

El tema creo que se confunde porque en los inicios de las Vistas estas no usaban las optimizaciones del servidor y te devolvían todos los datos, pero eso ya es del pasado y esa literatura quedo regada por el cyberespacio, pero ya no es así, ahora las vistas son optimizadas, cacheadas, etc etc.

saludos

Antonio Meza

[Víctor Hugo Espínola Domínguez]

No entiendo porqué tienen que comparar vista vs stored procedure, la vista es un conjunto de filas formadas por columnas, es un concepto análogo a tabla y/o cursor y su uso es el mismo que se le da a una tabla o cursor. Un SP es un programa, un conjunto ordenado lógicamente de instrucciones, comandos, sentencias como quieran llamarlo; por supuesto que ese "programa" puede producir el mismo resultado que se obtiene con una vista, pero no es ésa la única utilidad de un SP.

Siendo viernes se me ocurre comparar una parrilla para asar con un automóvil, porque ambos producen humo y puedo asar la carne sobre el motor del vehículo. Cuál es mejor? ;-)

Saludos,

Víctor.

Lambaré - Paraguay.

[mapner]

Victor, buena tu acotación, pero no es descabellado preguntar frente a una consulta de datos, cual es la herramienta más adecuada para realizarla, SQL directo, una Vista o un SP, y la respuesta es: depende.

Saludos

[Antonio Meza]

Yo tengo bien claro lo que es una Vista y un SP, lo que comente es que una vista no es tan tonta como antes lo era, ya usa todo lo necesario para ser optimizable, solo eso comente que hay mucha información desactualizada, y repito se la diferencia entre una vista y un SP. jajajaja

saludos

Antonio Meza

[Carlos Miguel FARIAS]

Mapner y Antonio tiraron un montón de justas complementarias.

Dados:

sqlexec(conexion, "SELECT t.a, t.b, u.c, t.d, u.d FROM t INNER JOIN u ON (t.a = u.a) WHERE t.e BETWEEN 20 AND 30", "unCursor")

y una vista creada con el SELECT anterior

sqlexec(conexion, "SELECT * FROM tu_vista", "unCursor")

la segunda va a ser más rápida porque cuando se creo la vista, esta se compiló en el servidor, si el SGBD es de los buenos, al compilar, analizó como optimizar la consulta, y sabe que tiene que hacer para responder optimizada la consulta. Y se toma su tiempo.

Luego, cuando se accede a la vista, todo ese proceso de optimización ya está hecho.

En el primer caso, al recibir la sentencia en crudo, todo lo que hizo el SGBD al momento de crear la vista, tiene que hacerlo, y puede ser significativo, lo que demora.

Y lo tiene que hacer cada vez que mandas la sentencia. Por lo tanto, es más lento.

Cuando puede ser más rápido el SP? Cuando reduce el trafico de red.

Un ejemplo: los triggers (que son básicamente SP) que responden a un evento en la BD.

Si no se usaran triggers, todo los eventos que estos detectan y lo que hacen en consecuencia, tendrían que hacer con múltiples controles desde los clientes (que puede colisionar entre si).

Otro ejemplo: Crear una lista jerárquica.

categorias = {idCategoria, cCategoria, idCategoriaPadre}

Si el SGBD no soporta consultas recursivas, cargar todo el arbol de dependencia puede implicar unas cuantas sentencias sql desde el cliente. Pasar los datos al cliente y armar.

Con un SP, se puede hacer en un servidor.

Víctor: Si logras hacer una parrillada sobre el motor del auto, me parece que te esta recalentando un poco (si fueran hamburguesas estilo McDonals es otra cosa).

Y es de muy mala educación hablar de parrillada los viernes, eso es cosa de los domingos.

Saludos: Miguel, La Pampa (RA)

Larga Vida y Prosperidad

Que la Fuerza los acompañe, y que Víctor combide

[Antonio Meza]

jajajaj así es Miguel!!!

En mi caso me refería a las vistas que son optimizables  y no compare nada con los SP, en fin viernes loco jajajaj