Заметки про запросы. Коллекция
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
В таком случае я иногда извращаюсь и пишу на чистом sql, благо 1С прекрасно понимает. До сих пор привычка писать запросы вручную без помощи конструктора запросов. За то есть понимание почему выбирается именно так, а не иначе.
SELECT
CASE
WHEN NULL IS NULL
THEN ИСТИНА
ELSE ЛОЖЬ
END AS Поле1
SELECT
CASE
WHEN NULL IS NULL
THEN ИСТИНА
ELSE ЛОЖЬ
END AS Поле1
При объединении двух таблиц в числовое поле лучше ставить 0, если поле планируем суммировать и Null, если будет функция Максимум (Минимум)
Вероятно, для любого настоящего спеца 1С это не вопрос уже, но лично я постоянно сталкиваюсь с таким баяном, даже в "типа навороченных" решениях. Допишите в свою коллекцию и выделите жирным:
Если при суммировании попадаются поля со значением Null, то в результате суммирования получится Null!
Отсюда хорошая привычка: если планируется результат полученного запроса дальше суммировать, то следует использовать конструкцию ЕСТЬNULL(ТаблицаИзКоторойВыбираем.МоеСуммируемоеПоле,0)
Разумеется, не забывая подставлять вторым параметром осмысленное выражение подходящего типа (дату - к дате, ссылку - к ссылке, число - к числу...).
А вообще, спасибо, хорошая подборка, если с умом к ней подходить!
(11)
Вы ошибаетесь. Результатом любого выражения с участием NULL будет NULL. Но в агрегатных функциях (в т.ч. в СУММА) строки с NULL просто игнорируются.
Иногда это можно использовать (при подсчете ссылок, например).
Просто если все детальные записи были с NULL, то и СУММА вернет NULL, поэтому и нужна проверка на NULL. Некоторые проверяют на NULL уже результат суммирования и это тоже вполне рабочее решение.
Если при суммировании попадаются поля со значением Null, то в результате суммирования получится Null!
Вы ошибаетесь. Результатом любого выражения с участием NULL будет NULL. Но в агрегатных функциях (в т.ч. в СУММА) строки с NULL просто игнорируются.
Иногда это можно использовать (при подсчете ссылок, например).
Просто если все детальные записи были с NULL, то и СУММА вернет NULL, поэтому и нужна проверка на NULL. Некоторые проверяют на NULL уже результат суммирования и это тоже вполне рабочее решение.
(11) (12) на платформе 8.2.19 запрос
ВЫБРАТЬ
2 КАК Поле1
ПОМЕСТИТЬ Таб1
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
NULL
;
////////////////////////////////////////////////////////////
ВЫБРАТЬ
СУММА(Таб1.Поле1) КАК Поле1
ИЗ
Таб1 КАК Таб1
возвращает 2.
ВЫБРАТЬ
2 КАК Поле1
ПОМЕСТИТЬ Таб1
ОБЪЕДИНИТЬ ВСЕ
ВЫБРАТЬ
NULL
;
////////////////////////////////////////////////////////////
ВЫБРАТЬ
СУММА(Таб1.Поле1) КАК Поле1
ИЗ
Таб1 КАК Таб1
возвращает 2.
"Вывести нумерованный список справочника с помощью запроса, если есть только наименование, нет кода"
в платформе с версии 8.3.13.1513 Упрощено создание монотонно возрастающего уникального ключевого поля для временной таблицы.
в платформе с версии 8.3.13.1513 Упрощено создание монотонно возрастающего уникального ключевого поля для временной таблицы.
Реализована возможность создания поля с уникальными (в рамках одной таблицы), последовательно возрастающими значениями.
Реализована функция языка запросов АВТОНОМЕРЗАПИСИ(), которая может быть использована только при создании временной таблицы.
Не поддерживается использование функции АВТОНОМЕРЗАПИСИ():
в запросах, содержащих ОБЪЕДИНИТЬ на верхнем уровне;
в запросах, не формирующих временную таблицу;
вне списка выборки;
в выражениях.
Реализована функция языка запросов АВТОНОМЕРЗАПИСИ(), которая может быть использована только при создании временной таблицы.
Не поддерживается использование функции АВТОНОМЕРЗАПИСИ():
в запросах, содержащих ОБЪЕДИНИТЬ на верхнем уровне;
в запросах, не формирующих временную таблицу;
вне списка выборки;
в выражениях.
"Аналог среза последних" - позволяет например, получить срез последних по определенному типу регистраторов, бывает нужно. Работает быстро.
"Неожиданный результат запроса" - ничего неожиданного, если помнить правило: Любое* математическое или агрегатное выражение с NULL - вернёт NULL, а любое* логическое выражение с NULL - всегда вернёт Ложь. Этим "NULL" отличается от "Неопределено".
* - Кроме двух специфичных функций ЕстьNULL() и Есть NULL, которые как раз используются для работы с NULL-значениями.
"Неожиданный результат запроса" - ничего неожиданного, если помнить правило: Любое* математическое или агрегатное выражение с NULL - вернёт NULL, а любое* логическое выражение с NULL - всегда вернёт Ложь. Этим "NULL" отличается от "Неопределено".
* - Кроме двух специфичных функций ЕстьNULL() и Есть NULL, которые как раз используются для работы с NULL-значениями.
(31) Аргумент "не рекомендуют" меня честно говоря каждый раз веселит :) Ну что за религия то. Как они хоть это объясняют то?
Кстати, всякие виртуальные таблицы, типа срезов последних, на сервер уходят как раз со вложенными запросами, и ничего.
Грамотно оформленные подзапросы могут существенно улучшить читабельность, и вообще упростить жизнь.
например, сравним
SEL ECT
...,
Данные.Поле1
FR OM
(
SEL ECT
... ,
CASE
WHEN ... THEN 10
WHEN ... THEN 20
WHEN ... THEN 30
END Поле1
FR OM
...
) Данные
WHERE
Данные.Поле1 >= 20
ORDER BY
Данные.Поле1
и
SELECT
... ,
CASE
WHEN ... THEN 10
WHEN ... THEN 20
WHEN ... THEN 30
END Поле1
FR OM
...
WH ERE
CASE
WHEN ... THEN 10
WHEN ... THEN 20
WHEN ... THEN 30
END >= 20
ORDER BY
CASE
WHEN ... THEN 10
WHEN ... THEN 20
WHEN ... THEN 30
END
Иной раз эти кейсы такие развесистые бывают, шоажкапец. А потом в этот кейс надо добавить ещё ветку, и редко когда это происходит с первого раза правильно (т.е. синхронно во всех местах).
Что же касается времени выполнения запроса, и его ресурсоемкости - то наличие/отсутствие подзапросов в подавляющем большинстве случаев никак не сказывается. Всё равно SQL сервер всё сделает как ему удобнее.
Кстати, всякие виртуальные таблицы, типа срезов последних, на сервер уходят как раз со вложенными запросами, и ничего.
Грамотно оформленные подзапросы могут существенно улучшить читабельность, и вообще упростить жизнь.
например, сравним
SEL ECT
...,
Данные.Поле1
FR OM
(
SEL ECT
... ,
CASE
WHEN ... THEN 10
WHEN ... THEN 20
WHEN ... THEN 30
END Поле1
FR OM
...
) Данные
WHERE
Данные.Поле1 >= 20
ORDER BY
Данные.Поле1
и
SELECT
... ,
CASE
WHEN ... THEN 10
WHEN ... THEN 20
WHEN ... THEN 30
END Поле1
FR OM
...
WH ERE
CASE
WHEN ... THEN 10
WHEN ... THEN 20
WHEN ... THEN 30
END >= 20
ORDER BY
CASE
WHEN ... THEN 10
WHEN ... THEN 20
WHEN ... THEN 30
END
Иной раз эти кейсы такие развесистые бывают, шоажкапец. А потом в этот кейс надо добавить ещё ветку, и редко когда это происходит с первого раза правильно (т.е. синхронно во всех местах).
Что же касается времени выполнения запроса, и его ресурсоемкости - то наличие/отсутствие подзапросов в подавляющем большинстве случаев никак не сказывается. Всё равно SQL сервер всё сделает как ему удобнее.
(32) Да просто злоупотреблять вложенными запросами не стоит. Хотя многие новички эту рекомендацию воспринимают как "никогда не используйте вложенные запросы!". Нужна золотая середина. Слишком сложные моно-запросы сложнее анализировать и выше вероятность, что оптимизатор запросов может лажануть (и лечить это будет сложнее). Особенно, если кроссплатформенность интересует. В том же postgresql оптимизатор запросов менее продвинутый, чем в mssql. Во всяком случае, у меня сложилось такое впечатление. Ну, в параметрах виртуальных таблиц точно не стоит вложенные запросы использовать :)
Но если вообще избегать вложенных запросов - так это другая крайность. Сплошь и рядом это совершенно ненужная декомпозиция и по производительности тоже не айс, так как у оптимизатора не остается шансов на выбор более эффективного плана выполнения.
Но если вообще избегать вложенных запросов - так это другая крайность. Сплошь и рядом это совершенно ненужная декомпозиция и по производительности тоже не айс, так как у оптимизатора не остается шансов на выбор более эффективного плана выполнения.
"Найти документ, для которого сумма всех последующих документов меньше заданной, а сумма всех последующих документов вместе с его суммой – больше заданной.".
Что за белиберда? Из-за этого дальше и читать не хочется....
Что за белиберда? Из-за этого дальше и читать не хочется....
как по мне некоторые решения повергают меня в ступор...
1) запрос в цикле
2) передача в предусловие конструкции "Выбрать... "
3) столько статей по декартову произведению, а тут нумерацию "накопительным итогом" предлагают ;)
может для самописных мелких баз это еще сгодится, но для масштабируемых решений это погибель
1) запрос в цикле
2) передача в предусловие конструкции "Выбрать... "
3) столько статей по декартову произведению, а тут нумерацию "накопительным итогом" предлагают ;)
может для самописных мелких баз это еще сгодится, но для масштабируемых решений это погибель
(38)
Там по сути и есть декартово произведение. То, что условие отбора в соединении, а не в ГДЕ - непринципиально. Так просто более компактно.
Но судя по вашему снисходительному замечанию, вы можете предложить более оптимальный вариант нумерации строк в запросе. Очень хотелось бы на него посмотреть.
3) столько статей по декартову произведению, а тут нумерацию "накопительным итогом" предлагают ;)
Там по сути и есть декартово произведение. То, что условие отбора в соединении, а не в ГДЕ - непринципиально. Так просто более компактно.
Но судя по вашему снисходительному замечанию, вы можете предложить более оптимальный вариант нумерации строк в запросе. Очень хотелось бы на него посмотреть.
Напишите ваше сообщение
(38)
1. Запрос в цикле - мне тоже неприятно. Однако процедура перепроведения документов за порождает именно запросы, именно в цикле. А здесь - красивая идея передавать временную таблицу внутрь цикла.
2. Поясните, что значит предусловие ?
3. Нумерация накопительным итогом - встречается на собеседованиях. Я предупредил.
(38)
1. Запрос в цикле - мне тоже неприятно. Однако процедура перепроведения документов за порождает именно запросы, именно в цикле. А здесь - красивая идея передавать временную таблицу внутрь цикла.
2. Поясните, что значит предусловие ?
3. Нумерация накопительным итогом - встречается на собеседованиях. Я предупредил.
(41)
1. Запрос в цикле - я бы заменил на генерацию 1 запроса из запроса-шаблона, и поиском в результате.
2. предусловие - это условие в виртуальной таблице (остатки, обороты, срез первых/последних)
3. Как для теории - решение хорошее, для высоко нагруженных систем, но как накопительный итог, а не нумерацию. нумерацию можно получить из СКД и выгрузкой/выводом на Ваше усмотрение
1. Запрос в цикле - я бы заменил на генерацию 1 запроса из запроса-шаблона, и поиском в результате.
2. предусловие - это условие в виртуальной таблице (остатки, обороты, срез первых/последних)
3. Как для теории - решение хорошее, для высоко нагруженных систем, но как накопительный итог, а не нумерацию. нумерацию можно получить из СКД и выгрузкой/выводом на Ваше усмотрение
(44) 1. Бывают ситуации, когда запрос исполняется в цикле. Как правило, между выполнением таких запросов меняются данные и сделать, как Вы пишете, невозможно. Пример я приводил.
2. Про виртуальную таблицу смотрите подробнее . После этой статьи я понял, что лучше в условиях виртуальной таблицы делать простой запрос.
3. Нумерация мне встретилась на собеседовании, причем просили реализовать именно в запросе, без СКД. В реальной жизни не встречал.
2. Про виртуальную таблицу смотрите подробнее . После этой статьи я понял, что лучше в условиях виртуальной таблицы делать простой запрос.
3. Нумерация мне встретилась на собеседовании, причем просили реализовать именно в запросе, без СКД. В реальной жизни не встречал.
Такой запрос с нумерацией быстрее в среднем в 2 раза на 1000 элементов.
ВЫБРАТЬ РАЗЛИЧНЫЕ
Справочник.Ссылка КАК Ссылка,
1 КАК Нумератор
ПОМЕСТИТЬ Таб1
ИЗ
Справочник.Справочник КАК Справочник
;
//////////////////////////////////////////////////////////// Показать
- слишком много условностей а ля "для которых нет совпадения"..., "может/не может"
- слишком много банальных идей
- слишком много не оптимальных по производительности решений без учета громадных таблиц
Вывод - изложенные наработки хороши, но фактически бесполезны на практике
- слишком много банальных идей
- слишком много не оптимальных по производительности решений без учета громадных таблиц
Вывод - изложенные наработки хороши, но фактически бесполезны на практике
(54) Здравствуйте !
я математик, привык везде определять область допустимых значений, граничные условия. Как иначе ?
Почитайте Дональда Кнута. Двадцать разновидностей сортировки. Смешные названия: гномья сортировка, глупая сортировка. Банально, да ?
Оптимизация в этой теме не рассматривается, так задумано.
Все о чем написал, сам использовал. Например за год расчет остатков на каждый день использовал два раза в отчетах, один раз на собеседовании.
Напишите свою статью. Обязательно плюс поставлю.
я математик, привык везде определять область допустимых значений, граничные условия. Как иначе ?
Почитайте Дональда Кнута. Двадцать разновидностей сортировки. Смешные названия: гномья сортировка, глупая сортировка. Банально, да ?
Оптимизация в этой теме не рассматривается, так задумано.
Все о чем написал, сам использовал. Например за год расчет остатков на каждый день использовал два раза в отчетах, один раз на собеседовании.
Напишите свою статью. Обязательно плюс поставлю.