2012-07-23 3 views
0

Я запускаю список сложных запросов в базе данных для определенного периода времени и времени (т. Е. 05/01/2012 по 05/31/2012). Затем мне нужно запустить те же запросы с 06/01/2012 по 06/30/2012. затем присоедините результаты к цели отчета.Повторное использование переменной таблицы?

В запросах я использовал несколько переменных таблицы для хранения временных данных. Поскольку база данных велика, размер переменной таблицы также большой. Есть ли способ, которым я могу повторно использовать эти переменные таблицы?

DROP, Truncate не будет работать. Нужно ли удалять все данные из таблицы @table? Если так, будет ли это медленным? Я должен сделать пакетное удаление для @table, поскольку у него много данных?

BTW, я должен поместить все запросы в один файл SP, не может вызывать функцию или другой SP из-за способа разработки системы.

благодаря

=============================

нет петли в запросах. она работает как:

выбрать ..... выберите ..... обновление ..... присоединиться ......

сделать набор запросов на дату 05/01/2012 в 05/31/2012. то для этого необходимо задать тот же набор запросов для 06/01/2012 по 06/30/2012.

В запросах есть много логических внутри, поэтому мы не можем объединить эти 2 в один набор запросов. из-за разработанной системы мы не можем вызывать функцию или SP для запроса. необходимо выполнить первый набор запросов, затем второй набор запросов в последовательности.

проблема в том, что данных слишком много, @table слишком велика. если мы можем повторно использовать @table, это решит проблему.

благодаря

===============================

да, прямо сейчас, одинаковые коды, повторите дважды для двух разных интервалов времени. однако в коде он имеет некоторые логические внутри, разные процессы, основанные на различии между дат-временем. Извините, я не могу опубликовать фактический код. Но процесс подобен SP с различным периодом datetime как параметрами.

Однако я не могу использовать функцию SP/в этом случае, поэтому вам придется дважды скопировать код того же кода. в идеале, понадобится использовать разные @table для каждого повтора кода (прямо сейчас, мне нужно повторить 3 раза), но из-за размера данных @table слишком велика, если я повторяю 3 раза (требуется несколько @table в каждом для выполнения логической части).

Возможно, мне лучше использовать временную таблицу? поэтому я могу отказаться от него, когда вы начнете новый «повтор»?

благодаря

+1

Возможно, вы сможете отобразить код. Повторное использование переменной таблицы подразумевает цикл, который, вероятно, не нужен. И даже с циклом переменная таблицы может не понадобиться. Кажется, на этот лук может быть много слоев. Чем больше пилинга вы сделаете для нас, тем лучше будет ваше конечное решение. –

+0

Я не понимаю логику, которую вы там разместили. 'select ... select ... update ... join' - что это значит? Как вы идете с мая по июнь? Как ваш код знает, как запустить отчеты за эти два месяца? У вас есть два почти одинаковых запроса, жестко закодированных с этими датами? –

+1

Я думаю, что вы пытаетесь микро-оптимизировать здесь. К сожалению, из-за ваших вариантов дизайна запроса это будет похоже на бритье ног яка, чтобы заставить его плавать быстрее. –

ответ

10

Переменная таблица не регистрируется в текущей базе данных, и не подлежат сделки. Почему вы думаете, что усечение или падение будут быстрее, чем удаление? Вы пробовали это?

DECLARE @f TABLE(id INT); 

INSERT @f SELECT 1; 

BEGIN TRANSACTION; 
DELETE @f WHERE id = 1; 
ROLLBACK TRANSACTION; 

SELECT id FROM @f; 

Результаты поиска. Теперь, если удаление было полностью зарегистрировано в текущей базе данных (это то, что делает DELETE медленнее, чем TRUNCATE для обычной таблицы пользователей), вы ожидали, что DELETE будет откат, а SELECT должен вернуть данные.Но нет, удаление не является частью транзакции. Вы могли бы логически заключить, что DELETE и TRUNCATE были бы очень похожи, если бы не совпадали, были ли разрешены последние.

Если вы должны использовать переменную таблицы, просто используйте delete. Если вы находите это медленным, это, вероятно, не из-за удаления, вероятно, потому, что вы повторно используете переменную таблицы в цикле, а не используете операцию на основе набора. Но, конечно, вы находитесь в лучшем положении, чем кто-либо из нас, чтобы проверить, насколько медленнее будет ваш код, если вы используете две разные переменные @table или повторно используете одну переменную таблицы и выдаете удаление между ними. Но я все же думаю, что весь ваш процесс нуждается в повторном исследовании, потому что он звучит для меня не оптимальным образом на многих уровнях.

1

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

CREATE TABLE #my_temp_table (column1 int, column2 varchar(max), ...) 
INSERT INTO #my_temp_table (column1, column2) VALUES (...) 
-- Use the temporary table here 
DELETE FROM #my_temp_table 
INSERT INTO #my_temp_table (column1, column2) VALUES (...) 
-- Use the temporary table again 
DROP TABLE #my_temp_table 

EDIT: Заявитель может сказать: «Я не могу использовать табличную переменную, поскольку она передается в моей хранимой процедуры с флагом ReadOnly». В этом случае он может получить некоторый пробег, чтобы преобразовать его во временную таблицу.

В качестве примечания, хотя документация SQL Server утверждает, что это не так, я видел экземпляры, где таблицы temp работают лучше, чем переменные таблицы. Я считаю, что это связано с тем, что я поставил свой TEMPDB на отдельный диск, у которого было много возможностей ввода-вывода.

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

+0

да, возможно, это способ сделать это. просто любопытно, у него должен быть способ «сбросить» переменную таблицы, так как это переменная, не так ли? Благодарю. – urlreader

+0

Как это отличается от удаления из переменной таблицы? Ваше утверждение, что таблица #temp всегда лучше, чем переменная таблицы? –

+0

Я думаю, что когда в # таблице есть много данных, отбрасывание, а затем создание # таблицы намного быстрее, чем удаление данных напрямую. – urlreader

Смежные вопросы