SQL - Tabla de temperatura: almacenamiento de todas las columnas en tabla temporal en comparación con la clave primaria

votos
2

Necesitaría crear una tabla temporal para propósitos de paginación. Yo seleccionaría todos los registros en una tabla temporal y luego haré un procesamiento adicional con ella.

Me pregunto cuál de los siguientes es un mejor enfoque:

1) Seleccione todas las columnas de mi tabla principal en la tabla de temperatura y luego pueda seleccionar las filas que necesitaría

O

2) Seleccione solo la clave primaria de la Tabla principal en la Tabla de temperatura y luego, unir con la Tabla principal más tarde?

¿Hay alguna consideración de tamaño cuando se trabaja con el enfoque 1 frente al enfoque 2?

[EDITAR]

Lo estoy preguntando porque habría hecho el primer acercamiento pero mirando PROCEDURE [dbo]. [Aspnet_Membership_FindUsersByName], que se incluyó con Membresía ASP.NET, están haciendo Approach 2

[EDIT2]

Con personas sin acceso al procedimiento almacenado:

  -- Insert into our temp table
INSERT IGNORE  INTO #PageIndexForUsers (UserId)
    SELECT u.UserId
    FROM   dbo.aspnet_Users u, dbo.aspnet_Membership m
    WHERE  u.ApplicationId = @ApplicationId AND m.UserId = u.UserId AND u.LoweredUserName LIKE LOWER(@UserNameToMatch)
    ORDER BY u.UserName


SELECT  u.UserName, m.Email, m.PasswordQuestion, m.Comment, m.IsApproved,
        m.CreateDate,
        m.LastLoginDate,
        u.LastActivityDate,
        m.LastPasswordChangedDate,
        u.UserId, m.IsLockedOut,
        m.LastLockoutDate
FROM   dbo.aspnet_Membership m, dbo.aspnet_Users u, #PageIndexForUsers p
WHERE  u.UserId = p.UserId AND u.UserId = m.UserId AND
       p.IndexId >= @PageLowerBound AND p.IndexId <= @PageUpperBound
ORDER BY u.UserName
Publicado el 09/12/2008 a las 16:01
fuente por usuario
En otros idiomas...                            


5 respuestas

votos
2

Una Variable de tabla sería preferible a una tabla temporal, si está dentro de sus restricciones.

La opción 2 usaría menos recursos, porque hay menos duplicación de datos.

Los puntos de Tony sobre que esto sea una lectura sucia son realmente algo que deberías considerar.

¿Puedes explicar cómo estás 'paginando' con tablas temporales? No es un método de búsqueda con el que esté familiarizado.

EDITAR: después de mirar la edición de su publicación, definitivamente debe usar una variable de tabla en este caso. Es menos para la limpieza y no apagará tanto el tempdb.

Además, es poco claro qué beneficio da esta tabla temporal. Si su objetivo es evitar que un usuario acceda a un objeto / aplicación, ¿por qué está agregando la parte sobre el mismo "solo restringida si está en esta página de tabla de datos en particular"? Parece una especie de agujero desde una perspectiva de seguridad.

La tabla temporal también puede eliminarse bastante, ya que selecciona de las mismas tablas.

Respondida el 09/12/2008 a las 16:15
fuente por usuario

votos
1

Con el enfoque 1, los datos en la tabla temporal pueden estar fuera de paso con los datos reales, es decir, si otras sesiones realizan cambios en los datos reales. Esto puede estar bien si solo está viendo una instantánea de los datos tomados en un cierto punto, pero sería peligroso si también estuviera actualizando la tabla real en función de los cambios realizados en la copia temporal.

Respondida el 09/12/2008 a las 16:04
fuente por usuario

votos
0

Una alternativa a la búsqueda (como lo hace mi empresa) es usar CTE.

Vea este ejemplo en http://softscenario.blogspot.com/2007/11/sql-2005-server-side-paging-using-cte.html

CREATE PROC GetPagedEmployees (@NumbersOnPage INT=25,@PageNumb INT = 1)
AS BEGIN

WITH AllEmployees AS
(SELECT ROW_NUMBER() OVER (Order by [Person].[Contact].[LastName]) AS RowID,
[FirstName],[MiddleName],[LastName],[EmailAddress] FROM [Person].[Contact])

SELECT [FirstName],[MiddleName],[LastName],[EmailAddress]
FROM AllEmployees WHERE RowID BETWEEN
((@PageNumb - 1) * @NumbersOnPage) + 1 AND @PageNumb * NumbersOnPage
ORDER BY RowID
Respondida el 09/07/2009 a las 09:40
fuente por usuario

votos
0

Piensa en ello de esta manera. Suponga que su consulta arrojará suficientes registros para poblar 1000 páginas. ¿Cuántos usuarios crees que realmente mirarían todas esas páginas? Al devolver solo los ID, no está devolviendo mucha información que puede o no necesitar ver. Por lo tanto, debería ahorrar en recursos de red y servidor. Y si realmente atraviesan muchas páginas, llevaría suficiente tiempo que los datos de los datos deban refrescarse.

Respondida el 09/12/2008 a las 21:49
fuente por usuario

votos
0

Este es exactamente el enfoque que uso para Paginación en el servidor,

Cree una variable de tabla (¿por qué incurrir en la sobrecarga del registro de transacciones?) Con solo los valores clave. (Cree la tabla con una clave de identidad autónoma. Clave principal: esta será RowNum).

Inserte las claves en la tabla en función de los criterios de clasificación / filtrado de los usuarios. La columna de identidad ahora es un número de fila que se puede usar para paginación.

Seleccione de la tabla variable unida a otras tablas con datos reales requeridos, Unido al valor clave,

Where RowNum Between ((PageNumber-1) * PageSize) + 1 And PageNumber * PageSize
Respondida el 09/12/2008 a las 16:43
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more