¿Alguna vez has encontrado a una consulta de SQL Server no se pudo ejecutar debido a que se hace referencia demasiadas tablas?

Question

¿Alguna vez has visto alguna de que hay mensajes de error?

-- SQL Server 2000

No se pudo asignar la tabla auxiliar para ver o resolución de la función.
El número máximo de tablas en una consulta (256) se ha superado.

-- SQL Server 2005

Demasiados nombres de tabla en la consulta.El máximo permitido es de 256.

Si sí, ¿qué has hecho?

Dado?Convencido de que el cliente para simplificar sus demandas?Sin normalizar la base de datos?

---

@(todo el mundo me quiere publicar la consulta):

1. No estoy seguro de si puedo pegar 70 kilobytes de código en la respuesta ventana de edición.
2. Incluso si puedo esta esto no va a ayudar, ya que este 70 kilobytes de código de referencia de 20 o 30 puntos de vista que yo también tendría que publicar ya que de lo contrario el código no tendrá sentido.

No quiero sonar como que estoy presumiendo de aquí, pero el problema no está en las consultas.Las consultas son óptimas (o al menos casi óptima).He pasado incontables horas en la optimización de ellos, buscando cada columna y en cada mesa que se pueden eliminar.Imagine un informe que tiene 200 o 300 columnas que tiene que ser llenado con una sola instrucción SELECT (porque eso es lo que fue diseñado hace un par de años, cuando todavía era un pequeño informe).

Answer 1

Para SQL Server 2005, me gustaría recomendar el uso de la tabla de variables y parcialmente la construcción de los datos a medida que avanza.

Para ello, cree una variable de tabla que representa el resultado final que desee enviar al usuario.

A continuación encontrará la tabla principal (por ejemplo la tabla de pedidos en el ejemplo de arriba) y extraer los datos, además de un poco de información complementaria que es sólo decir una combinación de distancia (nombre del cliente, nombre del producto).Usted puede hacer un SELECT INTO para poner esto en claro en su variable de tabla.

Desde allí, recorrer la tabla y para cada fila, de hacer un montón de pequeñas consultas SELECT que recupera todos los datos complementarios que usted necesita para su conjunto de resultados.Insertar en cada columna de la marcha.

Una vez completado, usted puede hacer un simple SELECT * from su variable de tabla y devuelve este conjunto de resultados para el usuario.

No tengo números para esto, pero ha habido tres instancias distintas en la que he trabajado hasta la fecha donde hacer estas consultas más pequeñas que se ha trabajado realmente más rápido que hacer una gran consulta de selección con un montón de combinaciones.

Answer 2

Nunca me he encontrado con este tipo de situación, y para ser honesto, la idea de hacer referencia a > 256 tablas en una consulta fils mí con una pesadilla mortal.

La primera pregunta debería probablemente por "¿por Qué tantos?", seguida de cerca por "lo que los bits de información I NO necesitan?" Yo estaría preocupado de que la cantidad de datos obtenidos de una consulta de comenzar el impacto en el rendimiento de la aplicación muy severamente, demasiado.

Answer 3

@chopeen Que podría cambiar la forma de cálculo de estas estadísticas, y en lugar de mantener una tabla independiente de todos los por-producto stats..cuando se coloca un pedido, el bucle a través de los productos y la actualización de los registros correspondientes en la tabla de estadísticas.Esto haría cambiar mucho el cálculo de la carga a la página de pago en lugar de correr todo en una enorme consulta cuando se ejecuta un informe.Por supuesto que hay algunas estadísticas que no se va a trabajar así de esta manera, por ejemplo,seguimiento de los clientes próxima compra después de la compra de un producto en particular.

Answer 4

Esto iba a pasar todo el tiempo en la escritura de Informes de Reporting Services para Dynamics CRM instalaciones que se ejecuta en SQL Server 2000.CRM tiene un bien normalizado de datos de esquema que resulta en una gran cantidad de combinaciones.De hecho, hay una revisión en torno a que el límite de 256 a una friolera de 260: http://support.microsoft.com/kb/818406 (siempre pensamos que esta es una gran broma de parte de el equipo de SQL Server).

La solución, como Dillie-O aludes, es la de identificar las "sub-une" (de preferencia que se utilizan varias veces) y el factor a temp-tabla de variables que, a continuación, utilizar en su principal combinaciones.Es una de las principales PIA y a menudo mata a rendimiento.Lo siento por usted.

@Kevin, el amor que tee -- dice todo :-).

Answer 5

Me gustaría ver a esa pregunta, pero me imagino que es algún problema con algún tipo de iterador, y mientras yo no puedo pensar en ninguna de las situaciones donde es posible, creo que es de un mal/caso/cursor o una tonelada de la mala aplicación de los puntos de vista.

Answer 6

Post de la consulta :D

También me siento como uno de los posibles problemas que podría tener una tonelada (leído 200+) de nombre/valor de las tablas que se podría condensar en una sola tabla de búsqueda.

Answer 7

Tuve este mismo problema...mi caja de desarrollo se ejecuta SQL Server 2008 (la vista funcionaba bien), pero en la producción (con SQL Server 2005) la opinión no.Terminé la creación de vistas para evitar esta limitación, el uso de las nuevas vistas como parte de la consulta en la vista que produjo el error.

Un poco tonto, teniendo en cuenta la lógica de ejecución es el mismo...

Answer 8

Tenía el mismo problema en SQL Server 2005 (trabajó en 2008) cuando yo quería crear una vista.He resuelto el problema mediante la creación de un procedimiento almacenado en lugar de una vista.