Table SQL - Temp: Stockage de toutes les colonnes dans la table temporaire par rapport à la clé primaire

Question

Je dois créer une table temporaire pour les besoins de pagination. Je sélectionnerais tous les enregistrements dans une table temporaire, puis j'effectuerais un traitement ultérieur avec celle-ci.

Je me demande qui de ce qui suit est une meilleure approche:

1) Sélectionner toutes les colonnes de ma table primaire dans la table temporaire et ensuite être capable de sélectionner les lignes que je aurais besoin

OU

2) Sélectionnez uniquement la clé primaire de la table primaire dans la table temporaire, puis rejoignez la table primaire plus tard?

Y a-t-il une considération de taille lorsque l'on travaille avec l'approche 1 et l'approche 2?

[EDIT]

Je demande parce que je l'aurais fait la première approche, mais regardant PROCEDURE [dbo]. [Aspnet_Membership_FindUsersByName], qui a été inclus avec ASP.NET adhésion, ils font approche 2

[EDIT2]

Avec personnes sans accès à la procédure stockée:

-- Insert into our temp table 
INSERT 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 

Answer 1

Une variable de table serait préférable à une table temporaire, si elle est comprise dans vos contraintes.

L'option 2 utiliserait moins de ressources, car il y a moins de duplication de données.

Les remarques de Tony à propos de cette mauvaise lecture sont vraiment quelque chose que vous devriez considérer. Pouvez-vous expliquer comment vous «paginez» avec les tables temporaires? Ce n'est pas une méthode de pagination que je connais.

EDIT: Après avoir vérifié votre publication, vous devez utiliser une variable de tableau dans ce cas. Son moins de nettoyage et vous ne soufflerez pas le tempdb tellement.

En outre, son genre de ne sait pas quel avantage cette table de temp donne. Si votre objectif est d'empêcher un utilisateur d'accéder à un objet/une application, alors pourquoi ajoutez-vous la partie à ce sujet "seulement restreinte si sur cette page de table de données particulière". Cela semble un peu troublant du point de vue de la sécurité.

La table temporaire peut également être éliminée car elle est sélectionnée dans les mêmes tables.

Answer 2

Avec l'approche 1, les données de la table temporaire peut être en décalage avec les données réelles, c'est-à-dire si d'autres sessions apportent des modifications aux données réelles. Cela peut être OK si vous visualisez simplement un instantané des données prises à un certain point, mais serait dangereux si vous étiez également en train de mettre à jour la table réelle en fonction des modifications apportées à la copie temporaire.

Answer 3

C'est exactement l'approche que je l'utilise pour Paging sur le serveur,

Créer une table des variables (pourquoi engager les frais généraux de journalisation des transactions?) Avec seulement les valeurs clés. (Créez la table avec une clé primaire de colonne d'identité Autonum - ce sera RowNum.

Insérez les clés dans la table en fonction des critères de tri/filtrage des utilisateurs. La colonne d'identité est désormais un numéro de ligne pouvant être utilisé pour la pagination.

Sélection de variable table jointe à d'autres tables avec de vraies données requises, la valeur clé Inscrit,

Where RowNum Between ((PageNumber-1) * PageSize) + 1 And PageNumber * PageSize 

Answer 4

penser de cette façon. Supposons que votre requête renvoie suffisamment d'enregistrements pour remplir 1000 pages. Combien d'utilisateurs pensez-vous vraiment regarder toutes ces pages? En ne renvoyant que les identifiants, vous ne renvoyez pas beaucoup d'informations que vous pourriez ou non avoir besoin de voir. Il devrait donc économiser sur les ressources réseau et serveur. Et s'ils passent vraiment par beaucoup de pages, il faudrait assez de temps pour que les détails des données puissent effectivement être rafraîchis.

Answer 5

Une alternative à la pagination (comme le fait mon entreprise) consiste à utiliser des CTE.

Découvrez cet exemple 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