SQL - Temp Table: Хранение всех столбцов в временной таблице по сравнению только с Первичным ключом

Question

Мне нужно создать временную таблицу для целей подкачки. Я бы выбрал все записи во временную таблицу, а затем провел бы дальнейшую обработку с ней.

Мне интересно, какой из следующих подходов лучше:

1) Выделите все столбцы моей Первичной таблицы во Временную таблицу и затем сможете выбрать нужные мне строки

OR

2) Выбрать только первичный ключ первичной таблицы во временную таблицу, а затем присоединиться к первичной таблице?

Есть ли соображения по размеру при работе с подходом 1 против подхода 2?

[EDIT]

Я спрашиваю, потому что я бы сделал первый подход, но, глядя на PROCEDURE [dbo]. [Aspnet_Membership_FindUsersByName], который был включен в членство ASP.NET, они используют подход 2

[EDIT2]

С людьми, не имеющими доступа к хранимой процедуре:

  -- 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

Переменная таблицы предпочтительнее временной таблицы, если она находится в пределах ваших ограничений.

Вариант 2 будет использовать меньше ресурсов, потому что будет меньше дублирования данных.

Точки Тони о том, что это грязное чтение, - это действительно то, что вы должны рассмотреть.

Можете ли вы объяснить, как вы «разбираетесь» с временными таблицами? Это не пейджинговый метод, с которым я знаком.

EDIT: Посмотрев на редактирование вашего поста, вы обязательно должны использовать переменную таблицы в этом случае. Его меньше убирают, и вы не будете так много раздувать tempdb.

Кроме того, не совсем понятно, какую пользу дает эта временная таблица. Если ваша цель состоит в том, чтобы запретить пользователю доступ к объекту / приложению, то почему вы добавляете часть о том, что он «ограничен только на этой конкретной странице таблицы данных». Это выглядит дырой с точки зрения безопасности.

Временная таблица также может быть в значительной степени исключена, поскольку она выбирается из тех же таблиц.

Answer 2

При подходе 1 данные в временной таблице могут не совпадать с реальными данными, т.е. если другие сеансы вносят изменения в реальные данные. Это может быть нормально, если вы просто просматриваете снимок данных, снятых в определенный момент, но было бы опасно, если вы также обновляли реальную таблицу на основе изменений, внесенных во временную копию.

Answer 3

Альтернатива пейджингу (как это делает моя компания) - использовать CTE.

Проверьте этот пример из 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

Answer 4

Думайте об этом так. Предположим, ваш запрос вернет достаточно записей, чтобы заполнить 1000 страниц. Как вы думаете, сколько пользователей действительно посмотрят все эти страницы? Возвращая только идентификаторы, вы не возвращаете много информации, которую вы можете или не должны видеть. Так что это должно сэкономить на сетевых и серверных ресурсах. И если они действительно просматривают много страниц, то может потребоваться достаточно времени для обновления данных.

Answer 5

Это именно тот подход, который я использую для пейджинга на сервере,

Создайте переменную таблицы (зачем нести затраты на ведение журнала транзакций?), Используя только значения ключей. (Создайте таблицу с первичным ключом столбца автономных идентификаторов - это будет RowNum.)

Вставка ключей в таблицу на основе пользовательских критериев сортировки / фильтрации. Столбец идентификаторов теперь является номером строки, который можно использовать для подкачки.

Выбрать из табличной переменной, объединенной с другими таблицами с необходимыми реальными данными, Объединено по значению ключа,

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