Tanto Oracle como SQL Server, y también Mysql, (especialmente los dos primeros) tienen aplicativos específicos para crear ese tipo de vistas en forma de tabla inversa, y ninguno de ellos lo hace con tablas físicas.
Es un despropósito hacer tablas inversas por ciertas restricciones propias de esos sistemas.
Por lo pronto, este tipo de resumenes corresponden a OLAP, y en general a BI, para lo cual se diseñaron esos recursos, que se
alimentan de datos de bases relacionales, sin modificarlas. Generar ese tipo de resultados no requiere modificaciones estructurales a la base. Sólo optimización de consultas y procesos. Que luego, lso resultados se almacenen en tablas, no implica que las tablas de almacenamiento no sigan las mismas reglas ya defindias pra las tablas base.
Por otro lado, toda tabla tiene, en
todos los DBMS un límite de columnas posibles, que no existe en el concepto de tablas pivoteadas o inversas. No existe, porque en una tabla inversa podrían, segun el caso, existir desde 0 a N columnas, donde N sería cualquier numero entre 1 e infinito columnas (esto significa que podría haber tantas columnas como registros tenga la tabla). Y eso no hay DBMS que lo soporte.
En el caso de MySQL, hay limites definidos también:
Cita: There is a hard limit of 4096 columns per table, but the effective maximum may be less for a given table and depends on the factors discussed in Section D.10.4, “Limits on Table Column Count and Row Size”.
El tema tiene una explicacion y detalle algo más especifico en
http://dev.mysql.com/doc/refman/5.6/...unt-limit.html
Ahora bien, desde el punto de vista de la interacción entre aplicación y BBDD, no es conveniente crear tablas con un numero de columnas excesivamente grande, ya que se vuelve inmanejable en las consultas, y generan habitualmente un consumo de transacciones y datos demasiado elevando, sin justificación. Todo lo que se puede lograr con ese tipo de tablas, se puede obtener mucho más facilmente
procesando los datos en la base con tablas de salida normal, y luego pivoteandolas al momento de mostrar los datos. Eso es lo que, en definitiva, hacen las herramientas OLAP, solo que no se ve.
Adicionalmente, en los DBMS ya existen recursos de SQL para anlaizar cubos OLAP por medio de consultas, pero estor procesamientos de todos modos se basan en tablas no pivoteadas, aunque sea eso lo que terminan devolviendo.
Resumiendo: No es conveniente construirlas físicamente. Es mas optimizable crear los procesos de datos y luego mostrar las cosas como se desean.