Обращение к виртуальной таблице без параметров (VirtualTableCallWithoutParameters)¶
При использовании виртуальных таблиц в запросах, следует передавать в параметры таблиц все условия, относящиеся к данной виртуальной таблице.
Не рекомендуется обращаться к виртуальным таблицам при помощи условий в секции ГДЕ и т.п.
Такой запрос будет возвращать правильный (с точки зрения функциональности) результат, но СУБД будет намного сложнее выбрать оптимальный план для его выполнения. В некоторых случаях это может привести к ошибкам оптимизатора СУБД и значительному замедлению работы запроса.
Примеры¶
Например, следующий запрос использует секцию ГДЕ запроса для выборки из виртуальной таблицы:
Запрос.Текст = "ВЫБРАТЬ | Номенклатура |ИЗ | РегистрНакопления.ТоварыНаСкладах.Остатки() |ГДЕ | Склад = &Склад"; Возможно, что в результате выполнения этого запроса сначала будут выбраны все записи виртуальной таблицы, а затем из них будет отобрана часть, соответствующая заданному условию.
Рекомендуется ограничивать количество выбираемых записей на самом раннем этапе обработки запроса. Для этого следует передать условия в параметры виртуальной таблицы.
Запрос.Текст = "ВЫБРАТЬ | Номенклатура |ИЗ | РегистрНакопления.ТоварыНаСкладах.Остатки(, Склад = &Склад)"; Источники¶
- Источник: Стандарт: Обращения к виртуальным таблицам
- Источник: Стандарт: Эффективное обращение к виртуальной таблице «Остатки»
- Источник: Рекомендация 1С: Использование параметра Условие при обращении к виртуальной таблице
Сниппеты¶
Экранирование кода¶
// BSLLS:VirtualTableCallWithoutParameters-off // BSLLS:VirtualTableCallWithoutParameters-on Параметр конфигурационного файла¶
"VirtualTableCallWithoutParameters": false «Устройство виртуальной таблицы остатков» – бесплатные материалы из курса «Разработка и оптимизация запросов в 1С:Предприятие 8.2 и 8.3»
Статья описывает физическую реализацию виртуальной таблицы остатков конфигурации, работающей в клиент-серверном режиме работы на примере использования СУБД MS SQL Server.
Применимость
В статье рассматривается платформа «1С:Предприятие» редакции 8.3.5.1383. В актуальной версии платформы возможны некоторые изменения в тексте, описанного в материале, запроса T-SQL, выполняемого на стороне сервера СУБД.
Устройство виртуальной таблицы остатков
Рассмотрим, в какой запрос к СУБД трансформируется запрос с использованием виртуальной таблицы остатков регистра накопления. Для примера будет рассматриваться следующий текст запроса:
ВЫБРАТЬ
ТоварныеЗапасыОстатки.Товар ,
ТоварныеЗапасыОстатки.Склад ,
ТоварныеЗапасыОстатки.КоличествоОстаток
ИЗ
РегистрНакопления.ТоварныеЗапасы.Остатки ( &Дата , Склад = &Склад ) КАК
ТоварныеЗапасыОстатки
Сначала при помощи метода глобального контекста ПолучитьСтруктуруХраненияБазыДанных() получим список таблиц базы данных, в которых хранятся данные регистра накопления «ТоварныеЗапасы»:
Состав полей основной таблицы регистра накопления и таблицы итогов приведен ниже:
Хранение итогов для данного регистра настроено в режиме «1С:Предприятие 8» следующим образом:
Параметры в рассматриваемом запросе заполним следующим образом:
Платформа преобразует текст запроса в следующий запрос, который и будет выполнен на сервере СУБД:
SELECT
Q_000_T_001.Fld82 ,
Q_000_T_001.Fld83 ,
Q_000_T_001.Fld84Balance
FROM
( SELECT Fld82 ,
Fld83 ,
SUM ( Fld84Balance ) AS Fld84Balance
FROM
( SELECT Fld82 ,
Fld83 ,
SUM ( Fld84 ) AS Fld84Balance
FROM AccumRgT85
WHERE Period = DATETIME ( 3999 , 11 , 1 )
AND (( Fld83 = 9:a9b000055d49b45e11db8b8bee7616e1 ))
AND ( Fld84 <> 0 ) AND ( Fld84 <> 0 )
GROUP BY Fld82 , Fld83
HAVING Fld84Balance <> 0
UNION ALL
SELECT Fld82 ,
Fld83 ,
SUM ( CASE WHEN RecordKind = 0 THEN – Fld84 ELSE Fld84 END ) AS Fld84Balance
FROM AccumRg81
WHERE Period >= DATETIME ( 2012 , 9 , 1 )
AND Period < DATETIME ( 3999 , 11 , 1 )
AND Active
AND (( Fld83 = 9:a9b000055d49b45e11db8b8bee7616e1 ))
GROUP BY Fld82 , Fld83
HAVING Fld84Balance <> 0 ) T
GROUP BY Fld82 , Fld83
HAVING Fld84Balance <> 0 ) Q_000_T_001
Разберем подробнее полученный запрос.
Сначала при помощи первого запроса, входящего в объединение, выбираются данные из итоговой таблицы AccumRgT85. Итоги получаются на дату хранения текущих итогов (01.11.3999), дополнительно накладывается условие на поле Склад (поскольку такое условие использовалось в параметрах виртуальной таблицы). Дополнительно выполняется проверка на отсутствие в результате строк с нулевыми остатками.
Обратите внимание, что производится группировка по выбранным в тексте запроса измерениям. Именно поэтому не требуется в тексте на языке запросов «1С:Предприятие» дополнительно выполнять группировку по измерениям.
Во втором запросе объединения используется таблица движений регистра AccumRg81. В зависимости от вида движения (если RecordKind равно 0, то это Приход, в противном случае – Расход) проставляется знак в выражении. Платформа выбирает данные за период с даты, указанной в качестве параметра виртуальной таблицы, по дату хранения текущих итогов (01.11.3999).
Кроме этого отбираются только активные записи, поле Склад должно быть равно заданному значению. Как и в первом запросе объединения, здесь также производится группировка по выбранным измерениям и отбрасываются записи с нулевыми значениями ресурсов.
Если используется СУБД MS SQL Server и для базы данных установлено смещение дат 2000, то все даты будут храниться с указанным смещением, т.е. вместо 01.11.3999 Вы увидите 01.11.5999.
Если для регистра накопления отключить текущие итоги, то платформа сначала получит последние итоги, рассчитанные на дату, раньше указанной в параметре Период виртуальной таблицы.
Затем аналогично эти данные будут дополнены из таблицы движений, но только за период с даты последних итогов по период виртуальной таблицы.
SELECT
Q_000_T_001.Fld82 ,
Q_000_T_001.Fld83 ,
Q_000_T_001.Fld84Balance
FROM
( SELECT Fld82 ,
Fld83 ,
SUM ( Fld84Balance ) AS Fld84Balance
FROM
( SELECT Fld82 ,
Fld83 ,
SUM ( Fld84 ) AS Fld84Balance
FROM AccumRgT85
WHERE Period = DATETIME ( 2012 , 4 , 1 )
AND (( Fld83 = 9:a9b000055d49b45e11db8b8bee7616e1 ))
AND ( Fld84 <> 0 )
AND ( Fld84 <> 0 )
GROUP BY Fld82 , Fld83
HAVING Fld84Balance <> 0
UNION ALL
SELECT Fld82 ,
Fld83 ,
SUM ( CASE WHEN RecordKind = 0 THEN Fld84 ELSE – Fld84 END ) AS Fld84Balance
FROM AccumRg81
WHERE Period >= DATETIME ( 2012 , 4 , 1 )
AND Period < DATETIME ( 2012 , 9 , 1 )
AND Active
AND (( Fld83 = 9:a9b000055d49b45e11db8b8bee7616e1 ))
GROUP BY Fld82 , Fld83
HAVING Fld84Balance <> 0 ) T
GROUP BY Fld82 , Fld83
HAVING Fld84Balance <> 0 ) Q_000_T_001
Обратите внимание на следующее условие в тексте запроса:
Period < DATETIME ( 2012 , 9 , 1 )
То есть движения с периодом, равным параметру виртуальной таблицы, не будут учитываться при получении остатков. Ранее упоминалось, что таблица остатков строится на начало секунды, не включая указанный период.
Таким образом, таблица итогов регистра накопления позволяет оптимизировать получение остатков.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Статья в PDF-формате
Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.
P.S.
Понимать, как работают запросы и уметь их строить — обязательный навык для всех, кто дорабатывает и внедряет 1С.
После курса Вы сможете:
- Строить сложные запросы с несколькими источниками данных
- Уверенно задействовать вложенные запросы и временные таблицы
- Использовать встроенный язык для обработки результатов запроса
- Учитывать особенности соединений и объединений нескольких таблиц.
- Разрабатывать запросы на уровне задач Аттестации 1С:Специалист по платформе.
Программа, стоимость, условия и регистрация в группу: «Запросы в 1С 8.3, Базовый курс (с нуля до уровня Специалист по платформе)» Для всех, кто внедряет и дорабатывает 1С.
Как работают виртуальные таблицы Остатки, Обороты, ОстаткиИОбороты, особенности применения в СКД. Особенности объекта СтандартныйПериод
Рассмотрим виртуальные таблицы в СКД 1С: Обороты, Остатки, ОстаткиИобороты.
Дано: регистр накопления(остатки) в котором есть запись на 31.12.2021 23:59:59
Виртуальная таблица Остатки строится на начало секунды, указанной в параметре Период, другими словами не включают дату. Об этом рассказано в статье ИТС Особенности использования периодов и моментов времени при получении остатков. Таким образом следующий запрос:
ВЫБРАТЬ Остатки.Товар КАК Товар, Остатки.Склад КАК Склад, Остатки.КоличествоОстаток КАК Остаток ИЗ РегистрНакопления.ТоварныеЗапасы.Остатки(&Период, Товар = &Товар) КАК Остатки
при использовании различных параметров приведет к разным результатам
| Период | Остаток | Примечание |
| 31.12.2021 23:59:59 | 10 | Остаток на начало секунды. Не совсем то что мы хотели |
| 01.01.2022 0:00:00 | 9 | Остаток на начало следующей секунды. То что нужно! |
| Граница Включая; 31.12.2021 23:59:59 | 9 | Используется объект Граница с видом Включая. То что нужно! |
Виртуальные таблицы Обороты, Остатки и обороты включают дату начала и дата окончания. Об этом написано в статье ИТС Особенности использования периодов и моментов времени при получении оборотов. Проверим это следующим запросом:
ВЫБРАТЬ Обороты.Товар КАК Товар, Обороты.Склад КАК Склад, Обороты.КоличествоОборот КАК Количество ИЗ РегистрНакопления.ТоварныеЗапасы.Обороты(&НачалоПериода, &КонецПериода, , Товар = &Товар) КАК Обороты
При параметрах НачалоПериода = 01.01.2021 12:00:00 и КонецПериода = 31.12.2021 23:59:59 получаем значение в поле Количество = 9
Также существует миф что СКД учитывает остатки на конец секунды когда передаем параметр период в виртуальную таблицу Остатки. Но это не так, так как в наборе данных запрос используется обычный запрос. Поэтому при получении остатков также следует учитывать то что остатки будут получены на начало секунды, и позаботиться о том чтобы установить значение параметра период +1 секунда.
Важно! при использовании объекта Стандартный период — дата начала это начало дня, дата окончания это всегда конец дня, если дата окончания указана. При такой настройке параметров
если в параметре СтандартныйПериод выбрать 01.12.2021 — 31.12.2021, то значения параметров НачалоПериода, КонецПериода будут вычислены начало и конец дня, соответственно:
Это интересно. В то же время при передаче в функцию ДобавитьКДате() параметра Стандартный период.ДатаОкончания если дата окончания не заполнена то результатом вычисления функции будет пустая дата. Другими словами, дополнительно проверять, что значение заполнено не требуется.
СтандартныйПериод с пустой датой окончания и значение параметра ДатаОстатков:
В итоге, учитывая все вышеперечисленное всегда стоит помнить, что при использовании виртуальной таблицы остатки при получении остатков всегда надо добавлять секунду к периоду, даже если используется объект Стандартный период.
Какой запрос строится не sql когда мы обращаемся к таблице остатков
(9) из «физики» регистров накопления «присутствуют»:
_AccumReg — таблица движений регистра накопления.
_AccumRegTotals — таблица итогов регистра накопления, если регистр поддерживает остатки.
_AccumRegTurnovers — таблица оборотов регистра накопления, если регистр поддерживает обороты.
_AccumRegChangeRec — таблица регистрации изменений регистра накопления. Создается, если регистр накопления участвует хотя бы в одном плане обмена.
_AccumRegOptions — таблица настроек хранения итогов регистров накопления одна на все регистры накопления.
Задавая параметры виртуальной таблицы, ты указываешь соответствующие «ограничения» этой вьюшки..
ЗЫ.. Вьюшки, как и процедуры могут быть прекомпилинованные (и храниться на сервере) так и «динамические».
(13) уважаемый, не нужно вводить людей в заблуждение. Нет views в SQL базе, созданные 8.0 для регистров..
(13) Это я все знаю, но это ведь таблицы, а не вьюшки непосредственно SQL Server. И корректность данных в этих таблицах поддерживается сервером 8.0, а не SQL Server. Так что, это что-то вроде вьюшки, но вьюшки сервера 8.0, а не SQL. Поправь, если я не прав?
выбрать первые 1 Остатки.КоличествоОстаток, «остатки»
из РегистрНакопления.ОстаткиТоваровКомпании.Остатки() Остатки
из жизни скл-сервера:
SELECT TOP 1
#V8TmpTable2_Q_000_T_001._Fld2486Balance f_1,
N’остатки’ f_2
FROM
(
SELECT
SUM(#V8TmpTable1_B._Fld2486Balance) _Fld2486Balance
FROM
(
SELECT
_AccumRegTotals2491._Fld2486 _Fld2486Balance
FROM
_AccumRegTotals2491 WITH(NOLOCK)
WHERE
_AccumRegTotals2491._Period = @P1
) #V8TmpTable1_B
) #V8TmpTable2_Q_000_T_001
вопросы? замечания? предложения?
🙂
(15) Расскажите, а где почитать на вьюшки сервера 1С:Предприятия 8.х :-)))
(18) я так мыслю, что нигде 🙂
вьюшки они на скл сервере, а не на сервере 1С:Предприятия 8.0 (и даже 8.1)
:))
(17) В (7) я писал, что мало что понимаю в SQL, так что позвольте глупый вопрос. В приведенном листинге запроса генерируемого 8кой для SQL Server создаются View что ли? Или там просто вложенный запрос? Или это одно и тоже?)))
(18) Нигде. В (15) я писал «что-то вроде вьюшки», а не вьюшка. И вы не ответили на мой вопрос в (15). Я утверждаю, что технология View для SQL Server 8кой не используется. Я не прав?
(20) я думаю что у Вас несколько абстрактные понятия про вьюшку. Это на ваш взгляд что.
а я думаю, что некто кому то зубы заговаривает)))
(21) +
Для справки.
Механизм представлений (view) является мощным средством языка SQL, позволяющим скрыть реальную структуру БД от некоторых пользователей за счет определения представления БД, которое реально является некоторым хранимым в БД запросом с именованными столбцами, а для пользователя ничем не отличается от базовой таблицы БД (с учетом технических ограничений). Любая реализация должна гарантировать, что состояние представляемой таблицы точно соответствует состоянию базовых таблиц, на которых определено представление.
Так вот.. виртуальная таблица это и есть «представление», которое «позволяет скрыть реальную структуру БД» и которое реально является запросом и для пользователя ничем не отличается от базовой таблицы БД.
Приэтом ГАРАНТИРУЕТСЯ, что данное «представление» ТОЧНО соответствует состоянию базовых таблиц, на которых определено представление.
никакие это не вьюхи а куски текстов запросов.
(23) Спасибо за разъяснение. Однако, хочу обратить внимание на последнее предложение:
«. При этом ГАРАНТИРУЕТСЯ, что данное «представление» ТОЧНО соответствует состоянию базовых таблиц, на которых определено представление. »
Вот это как раз и НЕ ГАРАНТИРУЕТСЯ применительно к тем таблицам, которые вы привели в (13) — остатки, обороты, ну и т.д. То есть, это не гарантируется на уровне SQL Server. Это как бы гарантирует сервер 1С: Предприятие 8.0. Но на практике, такое бывает не всегда, иначе для чего тогда существует возможность пересчета итогов?
(23) и что?)).. как из описания можно сделать вывод, что виртуальная таблица 8.0 проецируется на виртуальную (view) таблицу MS SQL?))
(24) Дай ссылку на отличия вьюхи от «кусков текстов запросов» :-)))
(25) это и гарантирует именно сиквел.. именно он возвращает в виртуальной таблице тоже, что Вы бы получили бы из «обычного» регистра :-)))
(26) Ключевое слово — ПРЕДСТАВЛЕНИЕ.. Любая «вьюха» это суть запрос к реальным таблицам сиквела. просто вьюха «скрывает» реальную физику. и всё. Именно поэтому и называется ВИРТУАЛЬНАЯ ТАБЛИЦА :-)))
У кого ЕМ под рукой и 8 ра под SQL. Наличиствуют ли явно отношения в разделе views .
(27) view в MSSQL имеет важное отличие от сгенерированного на лету запроса — для него хранится готовый план запроса
(28) нет. нету никаких вьюшек для 8.0. проверил только только..))..
тут чел зубы заговаривает.. надысь заговаривали зубы хэш функциями, теперичи — вьюшками))
(28) Нет.
(27) Гарантирует. Ха-ха. Вот я залезу в эту таблицу с остатками, исправлю там цифири, и что мне вернет 8чный запрос к виртуальной таблице. А что вернет запрос к реальной таблице? Разные цифры — поверь мне)))
вьюхами в SQL Server называются вполне конкретные объекты.
А если нет «живых» вьюшек на SQL сервере , то о каких ,простите, вюхах идет речь .
(33) Это я пытаюсь выяснить у avmlvm)))
(33) (34) неча выяснять.. все равно ничего не добьешся))..
(29) «view в MSSQL имеет важное отличие от сгенерированного на лету запроса — для него хранится готовый план запроса»
Не выдумывай. оптимизатор для вьюхи включается после её компиляции.. А компиляция бывает только если её вызвать явно или после первого обращения.
(31) Не фантазируй.
Смысл вьюхи ,как правило,уже иметь подготовленные данные исходя из кучи таблиц. И она все же явно должна жить в разделе views. А если там ее нет ?
avmlvm. Где же ее увидеть ?
avmlvm. Пролей свет.
(37) Чего не фантазируй-то)))))) Хочешь сказать, что я не смогу добиться логического расхождения данных в таблицах движений регистра и в таблице остатков?)))
(38) нет. смысл вьюхи это иметь «централизованный параметризованный запрос» к реально существующим таблицам.. И всё.
(40) я хочу сказать, что если ты поменяешь цифру в таблице _AccumRegTotals2491 то ты получишь одно и тоже.. что через виртуальную таблицу, что «напрямую».
«разбежка» между движениями и остатками к данному вопросу никакого отношения не имеет.
сейчас начнется подмена понятий и уход темы разговора в сторону. В результате дискуссии оппненты уважаемого avmlvm будут «посрамлены» изза незнания элементраных вещей. То, что эти самые «труизмы» не имеют отношения к теме дискуссии, значения иметь уже не будет))..
(41) ну это далеко не все, на что вьюхи способны. например через них можно не только читать данные, но и изменять.
(36) не выдумываю. Тогда если верить тебе, VIEW не отличается от просто сохранённого текста запроса, а это далеко не так. Не только планы запроса сохраняются, а их даже можно индексировать
Интересно. Если я создаю вьюху то иду в views и там с помощю конструктора или ручатми пишу КОД этой вюхи. Все вроде понятно. А как ее породить эту вьюху иначе. Кодец то придется прописыать все равно. Есть иные способы создания вьюх .
(38) не выдумывай.. читай об архитектуре клиент-сервер.. о том, что то или иное «представление» может «жить» как на стороне сервера.. так и на стороне клиента. От этого «представление» своей природы не меняет. Ещё раз.. есть «физическое» представление хранения данных (таблицы) и есть их «виртуальное представление» (вьюшки).. а где находятся вьюшки.. когда они коммпилируется — вопрос реализации. Аналогично кстати и с процедурами.. Процедуры могут храниться на сервере, а могут «приходить» с клиента (и жить в tmbdb)
(46) командами DDL
(45) дай ссылку на определение «просто сохранённого запроса». 🙂
остановитесь на мгновение [побежал за колой и попкорном]
(43) кстати.. Я в отличии от оппонентов привожу определения использованных понятий.. а в ответ только ассоциативные формулировки :-)))
Получается речь идет о вьюхах созданных на стороне клиента ?
(46) мдя-я-я.. как всё запущено.. RAD средства «убили» само понимание сути.. всё оказывается сводится к месту где «щёлкаешь мышкой».. а вот чЁ в результате получается — понимания нет. Печально однако 🙁
(42) Что ты подразумеваешь под словами «напрямую»? Я имею ввиду следующее: язык запросов 8.0 позволяет использовать таблицу движений, например, ТоварыНаСкладах. И виртуальную таблицу: ТоварыНаСкладахОстатки. Так вот, при ручном изменении данных в таблице _AccumRegTotalsNNNN, и сохранении их в первозданном виде в таблице _AccumRegNNNN, запросы написанные на языке 8.0 к таблице ТоварыНаСкладахОстатки и таблице ТоварыНаСкладах вернут разные результаты. Ты с этим не согласен?
Далее: «разбежка» между движениями и остатками к данному вопросу никакого отношения не имеет. «. Очень даже имеет. То что ты написал про механизм View MSSQL должно гарантировать отсутствие этих расхождений на уровне MSSQL. А этого нет. Разве не так? )))
(50) Беги, беги. Я уже)))))
(52) Получается что речь идёт о ВИРТУАЛЬНЫХ таблицах. О таблицах, которых «физически» НЕТ. О таблицах, которые на самом деле есть параметризованные SQL запросы «скрывающие» природу и архитектуру «физики» реализации.
Но понятие вируальной таблицы есть и в SQL сервере наряду с понятием вьюха.
create view и create table #N не одно и тоже.
(53) виртуальная таблица должна подразумевать наличие create view. так вот, для виртуальной таблицы 8.0 MS SQL не формирует динамически Create View. будем продолжать настаивать, что виртуальные таблицы 8.0 отображаются на виртуальные таблицы MS SQL?
прекольная ветка
Парни. Виртуальная таблица в терминах MSSQL это # или ##. А вьюха это вьюха.
Акела промахнулся, акела промахнулся :)))
А параметризованный запрос я могу и через executesql реализовать.
в SQL нет понятия «виртуальные таблицы». А # и ## зовутся «временные таблицы».
(54) «Так вот, при ручном изменении данных в таблице _AccumRegTotalsNNNN, и сохранении их в первозданном виде в таблице _AccumRegNNNN, запросы написанные на языке 8.0 к таблице ТоварыНаСкладахОстатки и таблице ТоварыНаСкладах вернут разные результаты. Ты с этим не согласен? «
Хм-м-м.. А зачем сравнивать «мягкое» и «мокрое». А УТВЕРЖДАЮ, что при Ваших исходных данных значение оборотов которое вернёт таблица ТоварыНаСкладах ПОЛНОСТЬЮ совпадёт с оборотами полученной из виртуальных таблиц ТоварыНаСкладахОстаткиИОбороты и ТоварыНаСкладахОбороты.
Именно это я и писал, когда говорил о ГАРАНТИРОВАННОСТИ
А целостность данных.. «актуальность» оборотов и остатков. Это абсолютно иной вопрос. и к вопросу «представлений» — отношение не имеет.
(60) верное замечание.. как я и говорил в (43) начали уводить тему))..
(63) +1
(59)+ Ага. Короче, я для себя вывод сделал, что тот самый механизм View, который заложен в MSSQL 8кой не используется. Собственно, я и раньше в этом не сомневался.
2avmlvm: Перечитав все заново я понял, что с тобой говорили о разных вещах. Да, ты прав, что изменение данных в таблице _AccumRegTotals не изменит получаемого результата, в том смысле, что если формировать запрос через 8ку, которая сгеренит свой текст запроса, на основе запроса к виртуальной таблице, или сформировать запрос напрямую к SQL Server минуя 8ку. Я-то имел ввиду другое. Я имел ввиду, что если бы сами таблицы итогов хранились как View, то всякие расхождения между движениями и итогами были бы невозможны — насколько это было бы лучше для производительности не знаю. НО! В результате получается, что виртуальная таблица, это как ни крути, но скорее «вьюшка» (специально беру в кавычки) заложенная в идеологии сервера «1С: Предприятия 8.0». Так как именно 8чный сервер преобразуется запрос к этой таблице в реальный запрос к таблице итогов.
(56) «Но понятие вируальной таблицы есть и в SQL сервере наряду с понятием вьюха»
Вы путаете наверное «временные таблицы» и «виртуальные таблицы»
(66) «Я имел ввиду, что если бы сами таблицы итогов хранились как View, то всякие расхождения между движениями и итогами были бы невозможны «
Ещё раз. «представление» (вьюха) это ВИРТУАЛЬНАЯ сущность.. сама по себе она ничего не хранит.. Это лишь только щёлочка, через которую мы смотрим на реальные вещи. И механизм «представления» НИ КАК. не способен «гарантировать» целостность данных.. Тут кстати мы «плавно переползаем» из обсуждения OLTP к OLAP :-))))
(64) 66й пост написал до прочтения 64. Вопрос по расхождения итогов и движений закрыт)))
(68) Давайте не будем переползать никуда))) Давайте вернемся к (1) и моей фразе:
«. механизм View, который заложен в MSSQL 8кой не используется. «. Что скажете насчет этого?
(60) Я тебе привиду цитату из «букваря» по Сиквелу (ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.ru/udb9/html/ada83c28-e8b7-45d9-b53c-b3d67c8820c8.htm). надеюсь будет полезно :-)))
Представление — это виртуальная таблица, содержимое которой определяется запросом. Как и настоящая таблица, представление состоит из совокупности именованных столбцов и строк данных. Пока представление не будет проиндексировано, оно не существует в базе данных как хранимая совокупность значений. Строки и столбцы данных извлекаются из таблиц, указанных в определяющем представление запросе и динамически создаваемых при обращениях к представлению.
Представление выполняет функцию фильтра базовых таблиц, на которые оно ссылается. Определяющий представление запрос может быть инициирован в одной или нескольких таблицах или в других представлениях текущей или других баз данных. Кроме того, для определения представлений с данными из нескольких гетерогенных источников можно использовать распределенные запросы. Это полезно, например, если нужно объединить структурированные подобным образом данные, относящиеся к разным серверам, каждый из которых хранит данные конкретного отдела организации.
На запросы данных посредством представлений не налагаются никакие ограничения; есть только несколько ограничений на изменение данных при помощи представлений.
ЗЫ.. ещё раз. обрати внимание. «Представление — это виртуальная таблица»
«перекури» и не ляпай больше глупостей ввиде » Виртуальная таблица в терминах MSSQL это # или ##. А вьюха это вьюха» :-)))