2010-02-02 15 views
8

Tengo una tabla de datos que se actualiza una vez por semana. Luego tengo una consulta que procesa estos datos y básicamente devuelve una lista de códigos y la cantidad de horas reservadas a esos códigos. Esta consulta es razonablemente complicada y tarda unos 5 segundos en ejecutarse.SQL View o Table

Esta información debe ser utilizada por muchas otras consultas en la base de datos, por lo que quiero ponerlo en un lugar que se pueda acceder fácilmente por otras consultas. Hacer esto a la vista parecía una buena idea, pero eso significa que cada vez que se llame a esta vista se volverá a ejecutar esta consulta, tomando 5 segundos, si hay muchas llamadas a esto de una vez, entonces va a causar el aplicación para reducir la velocidad.

Así que estaba pensando, sería mejor crear esta vista como una tabla cuando los datos se importen un lunes, ya que será la única vez que esto cambie. ¿Es esta la mejor idea, o estoy mirando esto de la manera incorrecta?

+0

SI pone esto en una tabla específica, no se olvide de indexarlo en los archivos que usarán las consultas que lo usan. – HLGEM

Respuesta

2

Trato los mismos problemas con la mayoría de mis proyectos.

Tenemos grandes cantidades de datos que deben ser reorganizados para diferentes propósitos. También nos beneficiamos de una cultura corporativa que se utiliza para los trabajos por lotes y los procesos de un día para otro, de modo que los usuarios conocen bien la naturaleza instantánea de los datos. Lo primero que la mayoría de los usuarios exportan a Excel es la información, por lo que no es un problema.

Usar tablas adicionales es una forma sensata de hacerlo aquí.

Personalmente prefiero estas tablas con un guión bajo.

_LargeUsefulData 

Esto me permite identificar fácilmente tablas de conveniencia de las entidades que desempeñan un papel activo en las operaciones normales del sistema.

2

Suena como una forma razonable de hacerlo.

Como la consulta es costosa, poner los resultados en una tabla de "informe" que será utilizada por otra aplicación suena como un buen compromiso.

Mientras los usuarios de estos datos estén contentos con el cambio tal como lo describe, su enfoque está bien.

0

Aún está "viendo" sus filas, ya sea en una tabla o en una vista de las filas de la tabla.

Primero trataría de optimizar su consulta (acceda a sus índices, tal vez agregue/actualice/cambie sus índices) y ejecútelo a través de un generador de perfiles. Los perfiladores proporcionan información maravillosa ... sobre el plan de decisión de su base de datos.

1

Si la estructura de su vista permite indexarla, puede crear una vista indizada (que en realidad es solo una copia de los datos actualizados siempre que se actualicen las tablas subyacentes).

No todas las consultas, sin embargo, permiten indexar una vista sobre ella.

Si sus datos no son un segundo a segundo real, entonces la creación de una tabla es OK.

0

Sí, es el primer paso en la dirección de un Almacén de datos :) Por supuesto, debe asegurarse de que su nueva tabla siempre se construya después de cada actualización semanal.

0

Me he enfrentado a tipos similares de problemas en mi soporte de producción donde tengo que manejar un gran datawarehouse. Básicamente, lo que hice fue crear tablas usando un script de shell. La secuencia de comandos shell ejecuta de esta manera:

  1. Si existe la tabla temporal, deje caer ella.
  2. ejecutar la consulta mediante la creación de una mesa gusta crear la tabla x como (seleccione ....)
  3. Use la tabla temporal y crean como las tablas temporales /sobresale.
  4. Coloque la tabla temporal si no la necesita ya no la necesita o consérvela si no cree que se comerá el disco espacio.

Todo esto se puede hacer usando un simple script de shell. Descubrí que es muy útil e incluso ahora funciona de manera efectiva.

Cuestiones relacionadas