¿Crear vista o usar innerjoins?

Tengo una base de datos normalizada, con claves externas / claves principales que dan una a muchas bases de datos.

Planeo acceder a esta base de datos con PHP para la pantalla básica de frontend / backend. Ahora, mi pregunta proviene de estas dos consultas ilustradas:

CREATE VIEW `view` AS SELECT functiondetails.Detail, functionnames.ID, functionnames.FunctionName, functionnames.Catogory FROM functiondetails INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID 

o

 SELECT functiondetails.Detail, functionnames.ID, functionnames.FunctionName, functionnames.Catogory FROM functiondetails INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID 

No hay ningún error en la consulta ya que he ejecutado ambos sin falta, pero mi pregunta general es esta:

si planeo constantemente hacer referencia a mucha información de mi base de datos. ¿No sería más fácil crear una vista, que luego se actualizará todo el tiempo con la información recién agregada, o sería una mejor práctica tener la segunda consulta en mi php real .. Ejemplo:

 $Query = $MySQli->prepare(" SELECT functiondetails.Detail, functionnames.ID, functionnames.FunctionName, functionnames.Catogory FROM functiondetails INNER JOIN functionnames ON functiondetails.AsscID = functionnames.ID ") $Query->execute(); $Results = $Query->fetch_results(); $Array = $Results->fetch_array(MYSQLI_ASSOC); 

¿O para seleccionar desde mi punto de vista?

 $Query = $MySQLi->prepare("SELECT * FROM `view`"); $Query->execute(); $Results = $Query->fetch_results(); $Array = $Results->fetch_array(MYSQLI_ASSOC); 

Entonces, ¿cuál sería un mejor método para consultar mi base de datos?

Las vistas son una capa de abstracción y la razón habitual para crear una capa de abstracción es proporcionarle una herramienta para facilitarle la vida.

Algunas de las grandes ventajas de usar vistas incluyen:

  1. Seguridad
    Puede controlar quién tiene acceso a ver sin otorgarles acceso a las tablas subyacentes.

  2. Aclaración
    A menudo, los encabezados de las columnas no son tan descriptivos como pueden ser. Las vistas le permiten agregar claridad a los datos que se devuelven.

  3. Actuación
    En cuanto a rendimiento, las vistas no te lastiman negativamente. Sin embargo, no verá una ganancia de rendimiento al usar vistas, ya que MySQL no admite vistas materializadas .

  4. Facilidad en la encoding
    Las vistas se pueden usar para reutilizar consultas complejas con menos espacio para el error del usuario.

  5. Facilidad de gestión
    Hace su vida más fácil cada vez que cambia el esquema de su tabla.

    Por ejemplo, supongamos que tiene una tabla que contiene las casas que tiene para la venta, homes_for_sale , pero más adelante decide que desea que esa mesa maneje todas las casas que alguna vez ha tenido para la venta / tiene para la venta actualmente, all_homes . Obviamente, el esquema de la nueva tabla sería muy diferente al primero.

    Si tiene un montón de consultas homes_for_sale de homes_for_sale , ahora debe revisar todo el código y actualizar todas las consultas. Esto lo abre a un error de usuario y a una pesadilla de administración.

    La mejor forma de abordar el cambio es reemplazar la tabla con una vista del mismo nombre. La vista devolvería el mismo esquema exacto que la tabla original, aunque el esquema real haya cambiado. Luego puede revisar su código a su propio ritmo, si es necesario, y actualizar sus llamadas de consulta.

Puede suponer que MySQL almacena los resultados de una vista en algún lugar, y las actualizaciones que resultan a medida que cambian los datos en las tablas subyacentes. MySQL no hace esto. Consultar una vista es exactamente como ejecutar la consulta.

Pero incluso puede ser peor el rendimiento que ejecutar la consulta SQL simple, porque MySQL puede acumular los resultados de la consulta base en una tabla temporal, de modo que puede utilizar cláusulas SQL adicionales en su consulta en contra de la vista. Digo “puede” porque varía según el algoritmo de visualización.

Consulte http://dev.mysql.com/doc/refman/5.6/en/view-algorithms.html para obtener una descripción de cómo MySQL utiliza el algoritmo “merge” o el algoritmo “temptable” para ejecutar una vista.

Si quiere vistas materializadas, hay una herramienta llamada FlexViews que mantiene vistas materializadas:

Flexviews es una implementación de vistas materializadas para MySQL. Incluye una API simple que se utiliza para crear vistas materializadas y actualizarlas. La ventaja de usar Flexviews es que las vistas materializadas se actualizan de forma incremental, es decir, las vistas se actualizan de manera eficiente mediante el uso de registros especiales que registran los cambios en las tablas de la base de datos. Flexviews incluye herramientas que crean y mantienen estos registros. Las vistas creadas por Flexviews incluyen soporte para JOINs y para todas las principales funciones de agregación.

Una vista es simplemente una consulta de texto almacenada. Puede aplicar DONDE y ORDEN contra ello, el plan de ejecución se calculará con las cláusulas que se tengan en cuenta. Creo que sería útil si quieres mantener tu código “limpio”. Lo que debe tener en cuenta es que es un poco más difícil modificar la vista, por lo que si no está seguro acerca de las columnas, o cambiará más tarde, adhiérase a una consulta.

¡Acerca del rendimiento es LO MISMO!

¡Atentamente!

Crear vista es preferible si usted es:

  • Seguro sobre las columnas requeridas
  • Desea reutilizar su vista en otro lugar también
  • Te gusta codificar de forma abstracta. (Ocultar detalles técnicos)
  • Necesita acceso rápido al crear un índice sobre él.
  • Acceso específico a pocos usuarios (punto tomado de los comentarios)

En cuanto a rendimiento, deberían ser iguales, pero la vista es mejor por algunas razones prácticas.

Prefiero las vistas porque fomenta una mejor reutilización y refactorización de las consultas complejas al modificarlas en un solo lugar en lugar de tener que copiar y pegar una versión más nueva en todas partes si utiliza la consulta en varios lugares.

También ejecutar una consulta de actualización en una vista puede parecer mucho más simple y más limpio, pero tenga en cuenta que a veces no puede actualizar varias columnas en una vista que pertenece a diferentes tablas subyacentes. Entonces, si tiene que actualizar 2 columnas diferentes, deberá ejecutar dos consultas de actualización diferentes.

Usar una vista también tiene sentido porque descarga la lógica de la base de datos compleja a la base de datos a la que pertenece en lugar de comstackrla en el código de la aplicación.

En el lado negativo de usar una vista, eso puede demorar un poco más en configurarse si no tiene preparada la herramienta de administración de la base de datos. Además, si tiene muchos puntos de vista, es probable que tenga que idear alguna forma de organizarlos y documentarlos. Esto se vuelve más complejo si las vistas comienzan a desarrollarse a partir de otras vistas. Por lo tanto, deberá planificar anticipadamente y mantener las dependencias.