SQL - Temp Tabel: Het opslaan van alle kolommen in tijdelijke tabel versus alleen Primaire sleutel

stemmen
2

Ik zou hebben om een ​​tijdelijke tabel te maken om te bladeren doeleinden. Ik zou het selecteren van alle records in een tijdelijke tabel en dan doen verdere verwerking met het.

Ik vraag me af welke van de volgende is een betere aanpak:

1) Selecteer alle kolommen van mijn primaire tabel in de tijdelijke tabel en vervolgens de mogelijkheid om de rijen ik zou moeten kiezen

OF

2) Selecteer alleen de primaire sleutel van de primaire tabel in de tijdelijke tabel en vervolgens verbinden met de primaire tabel later aan de hand?

Is er een groot overweging bij het werken met de aanpak van 1 versus aanpak 2?

[BEWERK]

Ik vraag omdat ik de eerste benadering zou hebben gedaan, maar te kijken naar PROCEDURE [dbo]. [Aspnet_Membership_FindUsersByName], dat werd opgenomen met ASP.NET Membership, doen ze Benadering 2

[EDIT2]

Met mensen zonder toegang tot de opgeslagen procedure:

  -- 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
De vraag is gesteld op 09/12/2008 om 16:01
bron van user
In andere talen...                            


5 antwoorden

stemmen
2

A Table variabele zou de voorkeur boven een temp tafel, als het binnen uw beperkingen.

Optie 2 zou minder grondstoffen worden gebruikt, omdat er minder duplicatie van data.

Tony's punten over het feit dat een vuile lees zijn echt iets wat je moet overwegen.

Kun je uitleggen hoe je bent 'paging' met tijdelijke tabellen? Het is niet een paging methode die ik ben bekend met.

EDIT: Na het bekijken van je post bewerken, moet u zeker gebruik maken van een tabel variabele in dit geval. Het is minder opruimen en je gewoon uitblazen de tempdb zo veel.

Ook zijn soort onduidelijk welk voordeel deze tijdelijke tabel geeft. Als uw doel is om een ​​gebruiker te stoppen van de toegang tot een object / applicaiton, waarom voegt u het deel over het feit dat "alleen beperkt indien op deze specifieke gegevens tabel op pagina". Het lijkt soort hole-y vanuit het oogpunt van beveiliging.

De tijdelijke tabel kunt vrijwel eveneens te worden geëlimineerd, want het selecteert uit dezelfde tabellen.

antwoordde op 09/12/2008 om 16:15
bron van user

stemmen
1

Bij benadering 1, kunnen de gegevens in de tijdelijke tabel zijn uit de pas met de echte data, dat wil zeggen als andere sessies wijzigingen aanbrengen in de echte data. Dit kan OK zijn als je gewoon bekijkt een momentopname van de maatregelen die op een bepaald punt gegevens, maar zou gevaarlijk zijn als je ook het updaten van de echte tabel op basis van wijzigingen in de tijdelijke kopie.

antwoordde op 09/12/2008 om 16:04
bron van user

stemmen
0

Een alternatief voor paging (de manier waarop mijn bedrijf doet het) is het CTE gebruiken.

Check out dit voorbeeld uit 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
antwoordde op 09/07/2009 om 09:40
bron van user

stemmen
0

Denk na over het op deze manier. Stel dat uw vraag zou genoeg zijn verslagen terug tot 1000 pagina's te vullen. Hoeveel gebruikers denk je dat zou echt kijken naar al die pagina? Door alleen retourneren van de id's, bent u niet veel van de informatie die u wel of niet moeten zien terug te keren. Dus het zou moeten besparen netwerkbronnen en server. En als ze echt gaan door een heleboel pagina's, zou het genoeg tijd dat de gegevens gegevens inderdaad nodig worden vernieuwd nemen.

antwoordde op 09/12/2008 om 21:49
bron van user

stemmen
0

Dit is precies de aanpak die ik gebruik voor Paging op de server,

Maak een tabel variabele (waarom de overhead van de transactie logging oplopen?) Met slechts de kernwaarden. (Maak de tafel met een autonum Identity kolom primaire sleutel -. Zal dit rownum)

Steek sleutels in de tabel gebaseerd op de gebruikers soort / filtering criteria .. Identity kolom is nu een rijnummer dat kan worden gebruikt om te bladeren.

U kunt kiezen uit tabelvariabele verbonden met andere tafels met echte data nodig, sinds op de belangrijkste waarde,

Where RowNum Between ((PageNumber-1) * PageSize) + 1 And PageNumber * PageSize
antwoordde op 09/12/2008 om 16:43
bron van user

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