¿Puede definir tablas "literales" en SQL?

Puede hacerlo en PostgreSQL:

=> select * from (values (1,7), (2,6), (3,13), (4,12), (5,9) ) x(id, count);
 id | count 
----+-------
  1 |     7
  2 |     6
  3 |    13
  4 |    12
  5 |     9

Http://www.postgresql.org/docs/8.2/static/sql-values.html

En SQL estándar (SQL 2003-ver http://savage.net.au/SQL/) puede utilizar:

INSERT INTO SomeTable(Id, Count) VALUES (1, 7), (2, 6), (3, 13), ...

Con un poco más de persecución, también puedes usar:

SELECT * FROM TABLE(VALUES (1,7), (2, 6), (3, 13), ...) AS SomeTable(Id, Count)

Si estos funcionan en MySQL es un problema separado, pero siempre puede pedir que se agregue, o agregarlo usted mismo (esa es la belleza del Código abierto).

En Microsoft T-SQL 2008 el formato es:

SELECT a, b FROM (VALUES (1, 2), (3, 4), (5, 6), (7, 8), (9, 10) ) AS MyTable(a, b)

Es decir, como Jonathan mencionó anteriormente, pero sin la palabra clave 'table'.

Véase:

• DE (T-SQL MSDN docs) (en derived-table), y
• Constructor de valor de tabla (T-SQL MSDN docs)

He encontrado este enlace Tablas Temporales Con MySQL

CREATE TEMPORARY TABLE TempTable ( ID int, Name char(100) ) TYPE=HEAP; 

INSERT INTO TempTable VALUES( 1, "Foo bar" ); 

SELECT * FROM TempTable; 

DROP TABLE TempTable;

CREAR TABLA TEMPORAL ( ID int, Nombre char(100) ) SELECCIONAR ....

Lea más en: http://dev.mysql.com/doc/refman/5.0/en/create-table.html

(cerca de la parte inferior )

Esto tiene la ventaja de que si hay algún problema al rellenar la tabla ( desajuste de tipo de datos ) la tabla se elimina automáticamente.

Una respuesta temprana usaba una cláusula FROM SELECT. Si es posible utilizar que porque ahorra el dolor de cabeza de la limpieza de la mesa.

Desventaja ( lo que puede no importar) con el DE SELECCIONAR es qué tan grande es el conjunto de datos creado. Una tabla temporal permite la indexación que puede ser crítica. Para la consulta posterior. Parece contrario a lo intuitivo, pero incluso con un conjunto de datos de tamaño mediano ( ~1000 filas), puede ser más rápido tener un índice creado para que la consulta funcione.

En una palabra, sí. Aún mejor IMO si su producto SQL admite expresiones de tabla comunes (CTE), es decir, más fácil a la vista que usar una subconsulta más el mismo CTE se puede usar varias veces, por ejemplo, esto para 'crear' una tabla de secuencia de enteros únicos entre 0 y 999 en SQL Server 2005 y superiores:

WITH Digits (nbr) AS 
(
 SELECT 0 AS nbr UNION ALL SELECT 1 UNION ALL SELECT 2 
 UNION ALL SELECT 3 UNION ALL SELECT 4 UNION ALL SELECT 5 
 UNION ALL SELECT 6 UNION ALL SELECT 7 UNION ALL SELECT 8 
 UNION ALL SELECT 9 
), 
Sequence (seq) AS
(
 SELECT Units.nbr + Tens.nbr + Hundreds.nbr 
   FROM Digits AS Units
        CROSS JOIN Digits AS Tens
        CROSS JOIN Digits AS Hundreds
)
SELECT S1.seq 
  FROM Sequence AS S1;

Excepto que realmente haría algo útil con la tabla de secuencia, por ejemplo, analizar los caracteres de una columna VARCHAR en una tabla base.

Sin EMBARGO, si está utilizando esta tabla, que consiste solo en valores literales, múltiples veces o en múltiples consultas, ¿por qué no convertirla en una tabla base en primer lugar? Cada base de datos que uso tiene una tabla de Secuencia de enteros (generalmente 100K filas) porque es muy útil en general.