First of all, it requires a CREATE statement. Presumably, they would want to add and remove table records on the fly – otherwise there would be no need for a dynamic statement to begin with. I’d be hesitant to have the application DROP and CREATE a table every time a query needs to be run. If you limit the changes to only occurring during a major update – it’s just as easy to skip the whole exercise and just include the UNION in the application itself.

Second, there is no guarantee that the tables have exactly the same column names and indexes.

Regarding the INFORMATION_SCHEMA, you would need to some how identify the tables that you need in the UNION. You might be able to limit it to tables that include some kind of secret/specific column name, but then that’s really a hack! You risk someone coming in and adding that column name to an unrelated table and breaking the query.

Regarding Bill’s comments… after going out and looking up RDF and orthogonally… I come to the conclusion that I’m a.) not storing XML in my database, and b.) not recommending that a developer with only a limited grasp of SQL go out and learn a new meta-language and then go out and learn SPARQL.

The biggest issue I see is that you have to update the union_tables data…..I would use a VIEW for that, accessing table names from the INFORMATION_SCHEMA database.

Alternatively, you can also use a MyISAM table for the underlying tables, and a MERGE table for the wrapper table (instead of UNIONs). There’s still the problem of keeping the MERGE table up to date, but the UNION disappears and now you can also use a fulltext index.

If you want a technology that can query data and metadata orthogonally, use RDF.