2010-02-08 25 views

Respuesta

89

#table hace referencia a una tabla temporal local (visible solo para el usuario que la creó).

##table se refiere a una tabla temporal global (visible para todos los usuarios).

@variableName se refiere a una variable que puede contener valores según su tipo.

aplausos

+19

Su definición de #table no es totalmente correcta. No se limita al usuario sino a la conexión. Si un usuario tiene múltiples conexiones, solo estará visible para la conexión que creó el #table en primer lugar. –

+0

@DavinStuder ha ofrecido una aclaración crucial. La distinción entre una tabla visible para el usuario vs.una tabla visible solo en la conexión actual es muy importante. – mirzmaster

5

# y ## tablas son tablas reales representados en la base de datos temporal. Estas tablas pueden tener índices y estadísticas, y se puede acceder a través de sprocs en una sesión (en el caso de una tabla temporal global, está disponible para todas las sesiones).

El @table es una variable de tabla.

Para más: http://www.sqlteam.com/article/temporary-tables

+4

Y la variable de la tabla también vivirá en la base de datos tempDB, si su tamaño es demasiado grande para mantenerla en la memoria. –

+0

¿No está seguro de por qué su respuesta fue rechazada, gimiente? Pensé que contenía información útil, especialmente sobre la base de datos temporal ... –

+0

Quizás porque el artículo contiene un error, que se señala en la sección de comentarios de ese artículo. – Alex

6

me centraría en las diferencias entre #table y @table. ## table es una tabla temporal global y para el registro en más de 10 años de uso de SQL Server todavía tengo que encontrar un caso de uso válido. Estoy seguro de que algunos existen, pero la naturaleza del objeto lo hace altamente inutilizable en mi humilde opinión.

La respuesta a @whiner por @marc_s es absolutamente cierta: es un mito prevaleciente que las variables de tabla siempre viven en la memoria. En realidad, es bastante común que una variable de tabla vaya al disco y funcione como una tabla temporal.

De todos modos sugiero leer sobre el conjunto de diferencias siguiendo los enlaces señalados por @Astander. La mayor parte de la diferencia implica limitaciones en lo que no se puede hacer con las variables @table.

+0

Tengo 5 procedimientos almacenados separados que realizan diferentes partes de un cálculo y generan un solo resultado. Para la auditoría, quiero ver valores intermedios y también lo hace el auditor. Ajusté mis procedimientos para descargar algunos en una tabla ## Temp para que ambos podamos verlos, pero no se conservan (solo son necesarios durante las auditorías). Hay un caso de uso válido para usted (en mi humilde opinión). – RyanfaeScotland

+0

@Ryan ¿por qué ## Table es válida cuando podría haber usado dbo.Table? No considero que sea un caso de uso válido cuando todo lo que ha hecho se salvó de escribir una declaración DROP. –

+2

No quiero otorgarle al auditor permisos DROP en mi base de datos. Tampoco quiero tener que regresar y ordenar después de que haya terminado. Con una tabla temporal, puede ejecutar la consulta tantas veces como quiera y sé que cuando termine no dejará una huella en la base de datos. – RyanfaeScotland

4
CREATE TABLE #t 

crea una tabla que sólo es visible y durante esa conexión el mismo usuario que crea otra conexión no será capaz de ver #t tabla a partir de la otra conexión.

CREATE TABLE ##t 

Crea una tabla temporal visible para otras conexiones. Pero la tabla se elimina cuando la conexión de creación finaliza.

0

si necesita una tabla temporal global única, crear su propia Uniqueidentifier con un prefijo/sufijo y soltar la ejecución posterior si un if object_id (.... El único inconveniente es que utiliza SQL dinámico y la necesidad de colocar de forma explícita.

Cuestiones relacionadas