demasiadas mesas; MySQL solo puede usar 61 tablas en una unión

Está utilizando un diseño EAV e intentando reconstruir una sola fila a partir de un número variable de atributos. Esto señala una de las muchas minas terrestres que encontrará al usar el diseño EAV:hay un límite práctico en la cantidad de uniones que puede hacer en una sola consulta SQL.

Especialmente en MySQL:hay un límite estricto, como ha descubierto. Pero incluso en otras marcas de RDBMS, existe un límite efectivo porque el costo de las uniones es geométrico con respecto a la cantidad de tablas.

Si usa EAV, no intente reconstruir una fila en SQL como si tuviera un diseño de base de datos convencional. En su lugar, obtenga los atributos como filas, ordenados por la identificación de la entidad. Luego, postprocesarlos en el código de su aplicación. Esto significa que no puede volcar los datos en un solo paso:debe escribir código para recorrer las filas de atributos y reformar cada fila de datos antes de que pueda generarlos.

EAV no es un diseño de base de datos conveniente. Usarlo tiene muchos inconvenientes costosos, y acabas de encontrarte con uno de ellos.

Ver http://www.simple-talk.com/opinion /artículos-de-opinion/mal-carma/ para una gran historia sobre cómo el uso de EAV condenó a un negocio.

Y también vea http://en.wikipedia.org/wiki/Inner-platform_effect porque EAV es un ejemplo de este Anti-patrón.

Entiendo la necesidad de admitir un conjunto dinámico de atributos por producto en un catálogo. Pero EAV va a matar su aplicación. Esto es lo que hago para admitir atributos dinámicos:

• Defina una columna real en la tabla base para cada atributo que sea común a todos los tipos de productos. Nombre del producto, precio, cantidad en stock, etc. Trabaja duro para imaginar el producto canónico entidad para que pueda incluir tantos atributos como sea posible en este conjunto.

• Defina una columna más de tipo TEXT para todos los atributos adicionales de cada tipo de producto dado. Almacenar en esta columna como LOB serializado de los atributos, en el formato que más te convenga:XML, JSON, YAML, tu propio DSL casero, etc.

  Trate esto como una sola columna en sus consultas SQL. Cualquier búsqueda, ordenación o visualización que necesite hacer en función de estos atributos requiere que obtenga el TEXT completo. blob en su aplicación, deserialícelo y analice los atributos usando el código de la aplicación.