varias - ¿Cómo funcionan las vistas de MySQL?

vistas mysql

Question

Cuando creo una vista, básicamente estoy creando una nueva tabla que se procesará automáticamente cuando se modifiquen los datos en una de las tablas a las que se une; ¿Es eso correcto?

Además, ¿por qué no puedo usar subconsultas en mi vista?

Answer 1

La diferencia es :

para la vista, solo puede tener subconsultas en la parte where, no en la parte from, por lo que

CREATE VIEW v AS SELECT * FROM foo WHERE id IN (SELECT id FROM bar)

funcionaría, pero al mismo tiempo obtiene una vista de solo lectura ... Una vista simple en una sola tabla permitiría actualizar "a través" de la vista a la tabla subyacente

Answer 2

También encontré el mismo problema (para mi sorpresa, porque mi búsqueda parece indicar que Oracle y MS sí lo admiten).

Evito esta limitación (al menos por ahora, hasta que se demuestre que no se puede usar) creando dos vistas adicionales para mi vista final.

Ejemplo:

CREATE VIEW Foo1 AS
SELECT * FROM t ORDER BY ID, InsertDate DESC
CREATE VIEW Foo2 AS
SELECT * FROM Foo1 GROUP BY ID
CREATE VIEW Foo AS
SELECT * FROM Foo2 ORDER BY ID

El ejemplo anterior básicamente tiene una tabla ''t'' que es una tabla temporal que contiene todas las revisiones. Mi ''Foo'' (vista) básicamente es una vista simple de solo mis revisiones más recientes de cada registro. Parece funcionar bien por ahora!

Actualizar:

No sé si este es otro error en MySQL 5.1, ¡pero el ejemplo anterior no funciona de hecho! El ''Foo1'' funciona como se esperaba, pero el ''Foo2'' parece ignorar el orden antes de agruparse, por lo que mi resultado final no es lo que se pretende. Incluso obtengo el mismo resultado si cambio el ''DESC'' por ''ASC'' (sorprendentemente).

Además, si lees el 17.5.1. Ver la sección de sintaxis , establece claramente:

"Se puede crear una vista a partir de muchos tipos de sentencias SELECT. Puede referirse a tablas base u otras vistas. Puede usar uniones, UNION y subconsultas".

Voy a actualizar mi base de datos a 5.6 e intentarlo de nuevo!

Answer 3

Una vista funciona como una tabla , pero no es una tabla. Nunca existe; es solo una instrucción SQL preparada que se ejecuta cuando hace referencia al nombre de la vista. ES DECIR:

CREATE VIEW foo AS
SELECT * FROM bar
SELECT * FROM foo

... es equivalente a correr:

SELECT x.*
FROM (SELECT * FROM bar) x

Un MySQLDump nunca contendrá filas para insertarse en una vista ...

Además, ¿por qué no puedo usar subconsultas en mi vista?

Eso, lamentablemente, es por diseño (aunque cuestionable). Existen numerosas limitaciones para las vistas de MySQL, que están documentadas: http://dev.mysql.com/doc/refman/5.0/en/create-view.html

Entonces, si es solo una tabla imaginaria / declaración preparada, ¿significa que teóricamente tiene el mismo rendimiento (o incluso menos) que una tabla / consulta normal?

No.
Una tabla puede tener índices asociados, lo que puede hacer que la recuperación de datos sea más rápida (a algún costo para insertar / actualizar). Algunas bases de datos admiten vistas "materializadas", que son vistas a las que se les pueden aplicar índices, lo que no debería sorprender que MySQL no sea compatible debido a la funcionalidad de vista limitada (que solo comenzó en v5 IIRC, muy tarde para el juego). ).

Como una vista es una tabla derivada, el rendimiento de la vista es tan bueno como la consulta en la que está construido. Si esa consulta apesta, el problema de rendimiento será simplemente una bola de nieve ... Dicho esto, al consultar una vista, si una referencia de columna de vista en la cláusula WHERE no está envuelta en una función (IE: WHERE v.column LIKE ... , no WHERE LOWER(t.column) LIKE ... ), el optimizador puede insertar los criterios (llamado predicado) en la consulta original, haciéndolo más rápido.