Отправляет email-рассылки с помощью сервиса Sendsay

Новости сайта ToySQL

Подписаться Бесплатная новостная рассылка Временно не выходит ,возобновит выход закрыта окончательно Подписчиков 72 RSS
←   Сентябрь 2002   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30


За последние 60 дней ни разу не выходила


Сайт рассылки: http://1csql.udmnet.ru
Открыта: 12-06-2002

Автор
toypaul

Статистика

72 подписчиков
0 за неделю
←   Все выпуски   →

Новости сайта ToySQL


Информационный Канал Subscribe.Ru

Приветствую Вас, уважаемый подписчик

Хочу сообщить всем пользователям (текущим и потенциальным) версии 2.0, что в новой версии 2.1 я хочу изменить синтаксис запросов к регистрам. Вот сообщение, размещенное мной на форуме sql.ru, связанное с этим:

Хотелось бы узнать у уважаемых форумистов является ли подзапрос полным эквивалентом обычной таблицы в запросе. Что я под этим понимаю? Применимы ли к результату подзапроса все операции, что и к обычной таблице. То есть соединение с другими таблицами, объединение, группировка по полям, сортировка агрегатные функции. Понятно, что результат подзапроса представляет собой с точки зрения теории ту же реляционную таблицу, но будут ли применимы к ней ВСЕ операции (все ключевые слова, функции и т.п.).

Есть ли какие-то ограничения на использование подзапросов в определенных конструкциях? Есть ли такие места где обычная таблица может использоваться, а подзапрос нет?

Почему я это спрашиваю. Передо мной стоит задача перевод с собственного языка запросов в T-SQL. В моем языке запросов будут иметь место такие конструкции, когда нужно будет
запись к одному объекту заменить не напрямую на запрос к одной таблице, а на запрос к нескольким таблицам (то есть на некоторый подзапрос). Сделать это можно двумя способами:

1. (Как делаю я сейчас) Запрос типа

select a.b,c.d from a,c where a.e = c.f

заменять на такую конструкцию

select a.b,c_1.d
from a,c_1 where a.e = c_1.f
union all
select a.b,c_2.d
from a,c_2 where a.e = c_2.f

Надеюсь пример понятен - то есть всю простые таблицы мы вносим внутрь сложного запроса

2. Как хотелось бы (так проще)

select a.b,c_1.d
from a,
(
select c_1.d,c_1.f from c_1
union all
select c_2.d,c_2.f from c_2
) c
where a.e = c.f

Во втором случае также меня терзают сомнения насчет эффективности. Дело в том, что в запрос мы можем записать так

select a.b,c.d from a,c
where a.e = c.f and a.l = 1000

То есть задаем некое ограничение, которое в первом случае будет также переносится в каждую составляющую union, во втором же случае фильтрация будет осущствляться позже. Хотя может быть во втором случае оптимизатор сможет найти зависимость и внесет ограничение внутрь подзапроса? Это меня также волнует может быть даже больше чем ограничения на использование подзапросов

Вот так вот. Длинно, но думаю понятно.

На данный момент известно (с большой вероятностью), что использование подзапросов для выборки ничем не отличается от обычных таблиц. Осталось изучить вопрос эффективности. Скорее всего, он будет решен положительно, поэтому новый синтаксис запросов будет выглядеть примерно так:

select Рег.Остаток(Количество) from Регистр.ОстаткиТоваров.Остатки(Период,ВыбИзм1,...,ВыбИзмН) Рег

select Рег.Сумма(Количество) from Регистр.Продажи.Обороты(НачПериод,КонПериод,ВыбИзм1,...,ВыбИзмН) Рег

select Рег.НачОст(Количество), Рег.Приход(Количество) from Регистр.ОстаткиТоваров.ОстаткиИОбороты(Период,ВыбИзм1,...,ВыбИзмН) Рег

Здесь ВыбИзм - будет либо единичный элемент, либо СЗ, либо фильтр (в терминах текущей версии)

Аналогично будут выглядеть запросы к периодическим реквизитам и бухитогам:

select БИ.Остаток(Количество) from БухИтоги.Остатки(Период,ВыбСубк1,...,ВыбСубкН) БИ

select БИ.СКД(Количество),БИ.ДО(Количество) from БухИтоги.ОстаткиИОбороты(Период,ВыбИзм1,...,ВыбИзм2) БИ

select Ист.Объект,Ист.Значение from Справочник.Номенклатура.История("Себестоимость",ДатаРекв) Ист

Таким образом сильно упрощается перевод запроса (а значит и уменьшается количество ошибок), а также термин вирутальная таблица находит свое реальное отражение в подзапросе, связанном с каждой такой таблице

Выслушаю все ваши замечания и предложения.

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное