SQL - Tabela Temp: Armazenar todas as colunas na tabela temporária contra apenas Chave primária

votos
2

Eu preciso criar uma tabela temporária para fins de paginação. Eu estaria selecionando todos os registros em uma tabela temporária e, em seguida, fazer mais processamento com ele.

Eu estou querendo saber qual das seguintes é uma abordagem melhor:

1) Selecione todas as colunas da minha tabela primária na tabela temporária e, em seguida, ser capaz de selecionar as linhas que eu precisaria

OU

2) Selecione somente a chave primária da tabela primária na tabela temporária e, em seguida, juntar com a tabela primária mais tarde?

Existe alguma consideração o tamanho quando se trabalha com a abordagem 1 versus abordagem 2?

[EDITAR]

Estou perguntando porque eu teria feito a primeira abordagem, mas olhando para PROCEDURE [dbo]. [Aspnet_Membership_FindUsersByName], que foi incluído com ASP.NET Membership, que estão fazendo Abordagem 2

[EDIT2]

Com as pessoas sem acesso ao procedimento armazenado:

  -- 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 09/12/2008 em 16:01
fonte usuário
Em outras línguas...                            


5 respostas

votos
2

Uma variável de tabela seria preferível a uma tabela temporária, se a sua dentro de suas limitações.

A opção 2 usar menos recursos, porque há menos duplicação de dados.

pontos de Tony sobre este ser uma leitura suja são realmente algo que você deve considerar.

Você pode explicar como você é 'paginação' com tabelas temporárias? Não é um método de paginação estou familiarizado.

EDIT: Depois de olhar para o seu posto de edição, você deve definitivamente usar uma variável de tabela neste caso. Sua a menos de limpeza e você não vai soprar o tempdb tanto.

Além disso, o seu tipo de claro o que se beneficiam dessa tabela temporária dá. Se o seu objectivo é impedir que um usuário acesse um objeto / applicaiton, então por que você está adicionando a parte sobre ele ser "restringe apenas se desta página tabela de dados em particular". Parece espécie de buraco-y a partir de uma perspectiva de segurança.

A tabela temporária pode ser praticamente eliminado também, uma vez que seleciona a partir das mesmas tabelas.

Respondeu 09/12/2008 em 16:15
fonte usuário

votos
1

Com a abordagem 1, os dados na tabela temporária pode estar fora de sintonia com os dados reais, ou seja, se outras sessões fazer alterações nos dados reais. Isso pode ser OK se você está apenas vendo um instantâneo dos dados obtidos em um determinado ponto, mas seria perigoso se você também estavam atualizando a tabela real com base nas alterações feitas na cópia temporária.

Respondeu 09/12/2008 em 16:04
fonte usuário

votos
0

Uma alternativa para paginação (a forma como a minha empresa faz isso) é usar CTE do.

Confira este exemplo de 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
Respondeu 09/07/2009 em 09:40
fonte usuário

votos
0

Pense nisso desta maneira. Suponha que a sua consulta retornaria registros suficientes para preencher 1.000 páginas. Como muitos usuários que você acha que realmente olhar para todas aquelas páginas? Por retornando somente os ids, você não está retornando um monte de informações que você pode ou não precisa ver. Por isso, deve economizar em recursos de rede e servidor. E se eles realmente passar por um monte de páginas, levaria tempo suficiente para que os detalhes de dados pode, na verdade precisa ser atualizada.

Respondeu 09/12/2008 em 21:49
fonte usuário

votos
0

Esta é exatamente a abordagem que eu uso para paginação no servidor,

Criar uma variável de tabela (por que incorrer a sobrecarga de log de transações?) Com apenas os valores de chave. (Criar a tabela com uma coluna AUTONUM Identidade Chave primária -. Este será rowNum)

Insira as chaves na tabela é baseada em usuários espécie critérios / filtragem .. coluna de identidade é agora um número de linha que pode ser usado para paginação.

Selecione a partir de variável de tabela se juntou a outras tabelas com dados reais necessários, Ingressou em valor de chave,

Where RowNum Between ((PageNumber-1) * PageSize) + 1 And PageNumber * PageSize
Respondeu 09/12/2008 em 16:43
fonte usuário

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