2010-12-13 23 views
20

Estoy trabajando en una aplicación web que implica crear una lista de restaurantes en varias listas como "Joe's must visit places". Ahora para cada restaurante y la lista, tengo la pantalla en la página web que calculaMysql VIEWS vs. PHP query

  • Cálculo de popularidad de un restaurante
  • popularidad de una lista
  • Número de listas restaurante está presente en

Actualmente Estoy usando sentencias de MySQL en PHP para esto, pero estoy planeando cambiar a MySQL VIEWS y hacer una declaración de selección simple en PHP ...

mi pregunta es, ¿Cuál es la ventaja/desventaja de utilizar VIEWS sobre la escritura de consultas SQL en PHP?

+0

Esta pregunta es IMO, demasiado amplia, ¿qué tipo de ventaja estás mirando? ¿Mantenibilidad del código? Velocidad de consulta? ¿o que? –

+0

¿por qué no publica su modelo ER o esquema? Entonces podemos sugerir formas de optimizarlo –

+0

Quería saber desde una perspectiva más amplia, necesito usar esto en múltiples proyectos. – Tarun

Respuesta

13

El uso de vistas agrega un nivel de abstracción : más tarde puede cambiar la estructura de sus tablas, y no tendrá que cambiar el código que muestra la información sobre las listas, porque aún consultará la vista (la definición de vista puede cambiar, sin embargo).

La principal diferencia es que las vistas se actualizan después de cada inserción, de modo que los datos están "listos" cada vez que consulta la vista, mientras que con su consulta personalizada MySQL calculará todo cada vez (hay algo de caché, por supuesto)

La conclusión es que si sus listas se actualizan con menos frecuencia de lo que se ven, verá algunas mejoras en el rendimiento al usar vistas.

+1

"las vistas se actualizan después de cada inserción" - ¿Qué quieres decir? ¿Implica que las vistas se computan y almacenan en caché de antemano? – jrharshath

+0

gracias, no sabía sobre el almacenamiento en caché en la vista mysql – Tarun

+0

Tal vez pueda consultar http://dev.mysql.com/doc/refman/5.7/en/view-algorithms.html si usa MySQL. Tienes dos formas, una tabla temporal y un modo en línea. Tanto en la vista SQL se ejecuta, en 'MERGE' se" pega "dentro del SQL que realiza la llamada, pero con' TEMPTABLE' se crea una tabla temporal y se completa con los datos de la consulta (para que se puedan liberar bloqueos). – PhoneixS

2

Si las tablas de las que intenta hacer vista no están sujetas a cambios frecuentes, definitivamente obtendrá un rendimiento, ya que solo está haciendo una simple selección de datos ya preparados. Pero tenga en cuenta el hecho de que esa vista no es algo que se hace "de una vez para siempre": cada cambio de contenido de una de las tablas hará que el motor de la base de datos haga "ver refrescante", por lo que otra consulta (consulta que está visualizando desde) debe llamarse a taki para tener en cuenta los cambios que se realizaron. En resumen:

¿Cambios infrecuentes? Actuación. Cambios frecuentes/constantes (agregando comunidad, comentando, evaluando sus restaurantes): mejor vaya con las consultas SQL.

3

Mi respuesta completa dependerá de varias cosas (desde la perspectiva de la aplicación):

  • haces va a permitir a los usuarios crear y compartir esas listas?
  • ¿pueden los usuarios crear listas de cualquier tipo, o simplemente conectando valores en plantillas de consultas existentes?

Asumiendo que tiene un par de listas predefinidas para mostrar:

Uso de puntos de vista ofrece un par de ventajas:

  • su código será más limpio
  • la consulta para generar las vistas no tendrán que ser analizadas cada vez por mysql.

no estoy seguro de esto: No creo que MySQL cachés vistas como sugiere Tomasz - Creo que no contienen puntos de vista "datos ya preparted".

Una desventaja es que la lógica involucrada en la creación de la lista va a la base de datos en lugar de vivir en su código PHP, algo a lo que soy muy contrario. En mi mundo, las bases de datos son para datos, y el código es para lógica.

Saludos

+0

¿Dónde he dicho esto? :) Dije solo que los cambios frecuentes en la base de datos (es decir, las inserciones en las tablas en las que consiste la vista) harían que la vista se actualizara constantemente y, por lo tanto, el rendimiento desaparecería. Y está bien, si se refiere a "vista de caché" como consulta de vista de almacenamiento en caché, sí, la consulta compilada se almacena y utiliza como tal cuando el usuario intenta recuperar datos de la vista. Las vistas no "contienen" datos, me refería solo al hecho de que ese motor de base de datos contiene los datos preparados para usar para ver, no se computa "sobre la marcha", por solicitud. –

+0

hmm. Seguramente he entendido mal. – jrharshath

+1

@TomaszKowalczyk ¿me puede vincular a dónde ve que los datos están preparados para su uso en una vista? Al leer, parece que las consultas se ejecutan como de costumbre en segundo plano (con uniones, uniones, etc.), por lo que en realidad no hay ningún beneficio de rendimiento. EDITAR: Creo que estás hablando de Vistas Temptables. No tienen índices, por lo que una tabla grande será muy lenta de consultar. No estoy seguro de que valga la pena, a menos que solo tenga un pequeño número de filas. –

3

La pregunta original sobre pros y contras, pero no ver mucho acerca de las desventajas de las respuestas hasta el momento.

¿No es una desventaja de las vistas que pueden darle la falsa comodidad de ejecutar una consulta simple? Por ejemplo, SELECCIONAR nombre de usuario FROM myview DONDE id = '1' Eso parece simple, pero ¿y si "myview" es un SELECTO realmente complejo ... ¿Quizás incluso construido en otras vistas? Terminas teniendo una consulta simple que, en el fondo, requiere mucho más trabajo que si hubieras escrito tu consulta desde cero.

He estado experimentando con vistas, y a pesar de los beneficios, aún no se han vendido por completo. Me interesaría escuchar lo que otros perciben sobre las desventajas de Views, en lugar de solo la línea del partido sobre por qué las vistas son tan geniales. Todavía podría hacer el cambio, pero me gustaría entender más sobre el rendimiento.

-1

Desventajas:

  • En mi opinión bases de datos se utilizan para la capa de datos y no es adecuado que poner código de negocio dentro de ellos. Reduce la capacidad de mantenimiento y contradice la separación limpia de las capas. Lo mismo se aplica a incluir el código comercial y los cálculos en los scripts de Java de las páginas web. Para el script java es aún más grave ya que crea amenazas de seguridad. El control de código fuente dentro de la base de datos también es otro problema.

  • Ahora que el código está dentro de la base de datos, también se agregan las complicaciones de seguridad y acceso (a las vistas y procedimientos almacenados).

  • Migrar una aplicación de un motor de base de datos a otro será mucho más difícil (ya que además de las consultas simples, los procedimientos almacenados/vistas, etc. posiblemente también sean diferentes). Si la base de datos solo trata de datos, entonces una capa de abstracción podría permitir cambiar el motor de la base de datos (al menos en cierta medida).

Ventajas:

  • mejoras de rendimiento leves (ya que los datos no se está saliendo de la base de datos para su procesamiento, se procesa la derecha dentro de la base de datos).

  • El código parecerá más limpio (ya que la suciedad está oculta dentro de las vistas de la base de datos, procedimientos almacenados, etc.).