Еникеев Марат | Руководитель проектов 1С | ГК «Комплексная автоматизация»

«Структурно-независимые базы данных в 1С»

В докладе расскажу об идеях построения гибких (содержащих в БД структуру данных) систем на платформе 1С. Рассмотрим: - варианты развития функциональности известных подсистем БСП "Дополнительные реквизиты/сведения"; - как они соотносятся с конфигурациями "Конвертация данных (2 и 3)" и "Система проектирования прикладных решений"; - причем здесь паттерн программирования Модель-Представление-Контроллер (MVC) и расширение “Характеристики” языка запросов СКД; - по-новому посмотрим на периодические независимые регистры сведений и возможности их использования. Коснемся вопросов интеграции такого рода систем с внешними, в частности использование пакетов\фабрик XDTO, проведём аналогии с пакетом EnterpriseData (универсальный формат обмена данными). Обозначим области применения таких систем и их ограничения, в частности возможные подходы к решению проблем версионирования, производительности, обеспечения целостности данных и специфику формирования отчетов. Рассмотрим практический опыт разработки/внедрения/сопровождения подобной структурно-независимой формации на примере запатентованного продукта учета ресурсов системы здравоохранения и его механизмов интеграции с федеральным сервисом Единой Государственной Информационной Системы Здравоохранения в разрезе Федерального Регистра Медицинских Работников и других регистров. Поговорим об использовании этих идей в целях: - прототипирования информационных систем на этапе сбора/анализа требований, - построения экспертных систем поддержки принятия решений (ЭСППР) на базе описанной архитектуры.

Заметки про запросы. Коллекция

0. vasilev2015 647 11.10.16 11:34 Сейчас в теме
Кто-то коллекционирует марки, а я собрал мини-коллекцию запросов, хотел с Вами поделиться.
Надеюсь, что мои комментарии представляют отдельную ценность.

Перейти к публикации

Комментарии
Сортировка: Древо
1. PowerBoy 2844 27.12.16 07:28 Сейчас в теме
ВЫБРАТЬ
	ВЫБОР
		КОГДА NULL ЕСТЬ NULL 
			ТОГДА ИСТИНА
		ИНАЧЕ ЛОЖЬ
	КОНЕЦ КАК Поле1


Мне кажется так правильней и предсказуемей
2. vasilev2015 647 27.12.16 08:58 Сейчас в теме
(1) да, я именно хотел показать, что равенство для NULL не работает.
3. artem_from_minsk 27.12.16 11:17 Сейчас в теме
В таком случае я иногда извращаюсь и пишу на чистом sql, благо 1С прекрасно понимает. До сих пор привычка писать запросы вручную без помощи конструктора запросов. За то есть понимание почему выбирается именно так, а не иначе.

SELECT
CASE
WHEN NULL IS NULL
THEN ИСТИНА
ELSE ЛОЖЬ
END AS Поле1
4. nofear 13 27.12.16 12:01 Сейчас в теме
"Вывести нумерованный список справочника с помощью запроса"
Жутко непроизводительное решение. Применимо только в том случае, если элементов - немного.
6. vasilev2015 647 27.12.16 12:33 Сейчас в теме
(4) Можете посоветовать быстрое решение для такой задачи ?
7. nofear 13 27.12.16 13:15 Сейчас в теме
(6) Другого решения (запросом) нет. Мое замечание касалось лишь того, что бездумно пользоваться предложенным вариантом нельзя.
9. vasilev2015 647 27.12.16 14:43 Сейчас в теме
5. bulpi 129 27.12.16 12:28 Сейчас в теме
8. herfis 256 27.12.16 13:58 Сейчас в теме
Ну, может, новичкам и будет интересно...
Что касается других задачек, решаемых запросами, просмотрите статьи Ильдаровича, начиная с "Минимализмов".
CyberCerber; +1 Ответить
10. vasilev2015 647 27.12.16 14:44 Сейчас в теме
(8) Ильдарович - Герой.
maxdmt; SunShinne; jONES1979; +3 Ответить
11. japopov 46 27.12.16 15:45 Сейчас в теме
При объединении двух таблиц в числовое поле лучше ставить 0, если поле планируем суммировать и Null, если будет функция Максимум (Минимум)


Вероятно, для любого настоящего спеца 1С это не вопрос уже, но лично я постоянно сталкиваюсь с таким баяном, даже в "типа навороченных" решениях. Допишите в свою коллекцию и выделите жирным:
Если при суммировании попадаются поля со значением Null, то в результате суммирования получится Null!
Отсюда хорошая привычка: если планируется результат полученного запроса дальше суммировать, то следует использовать конструкцию ЕСТЬNULL(ТаблицаИзКоторойВыбираем.МоеСуммируемоеПоле,0)
Разумеется, не забывая подставлять вторым параметром осмысленное выражение подходящего типа (дату - к дате, ссылку - к ссылке, число - к числу...).

А вообще, спасибо, хорошая подборка, если с умом к ней подходить!
12. herfis 256 27.12.16 16:07 Сейчас в теме
(11)
Если при суммировании попадаются поля со значением Null, то в результате суммирования получится Null!

Вы ошибаетесь. Результатом любого выражения с участием NULL будет NULL. Но в агрегатных функциях (в т.ч. в СУММА) строки с NULL просто игнорируются.
Иногда это можно использовать (при подсчете ссылок, например).
Просто если все детальные записи были с NULL, то и СУММА вернет NULL, поэтому и нужна проверка на NULL. Некоторые проверяют на NULL уже результат суммирования и это тоже вполне рабочее решение.
13. vasilev2015 647 27.12.16 16:17 Сейчас в теме
(11) (12) на платформе 8.2.19 запрос
ВЫБРАТЬ
2 КАК Поле1
ПОМЕСТИТЬ Таб1

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
NULL
;

////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ
СУММА(Таб1.Поле1) КАК Поле1
ИЗ
Таб1 КАК Таб1

возвращает 2.
JohnyDeath; +1 Ответить
14. JohnyDeath 291 28.12.16 00:07 Сейчас в теме
20. the1 314 28.12.16 14:00 Сейчас в теме
(13)
Имелось в виду что

ВЫБРАТЬ
0 + NULL КАК Поле1

Даст NULL
21. vasilev2015 647 28.12.16 14:31 Сейчас в теме
(20) Действительно. Добавлю в статью. Кому-то пригодится. Спасибо.
15. kuzyara 515 28.12.16 03:56 Сейчас в теме
Зачем в нумерованном списке запросом при обращении к справочнику использовано ключевое слово РАЗЛИЧНЫЕ? И вы в курсе, что получившийся список будет пронумерован не по наименованию, а в случайном порядке?
16. vasilev2015 647 28.12.16 09:02 Сейчас в теме
(15) Слово "РАЗЛИЧНЫЕ" не нужно. Про порядок я в курсе ))). Для нумерации по наименованию нужно сравнивать больше-меньше наименование. Однако, если после такой нумерации добавится еще один элемент с каким-то своим наименованием - порядок будет нарушен.
17. saudin 28.12.16 10:55 Сейчас в теме
"Вывести нумерованный список справочника с помощью запроса, если есть только наименование, нет кода" - есть ошибка. Теряется один элемент.
18. saudin 28.12.16 10:58 Сейчас в теме
Надо "ПО (Таб1.Ссылка <= Таб11.Ссылка)"
19. vasilev2015 647 28.12.16 11:04 Сейчас в теме
(18) Согласен, исправлю. Спасибо за внимательность. Хоть кто-то до конца дочитал )))
22. serg_infostart 285 28.12.16 14:35 Сейчас в теме
Не интересно, т.к. это все запросы, до которых можно дойти за приемлемое время в процессе работы.
Интересны были бы какие-то фичи, ускоряющие, уменьшающие код, улучшающие понимание, типа "Распределение в запросе" или "избавляемся от перебора"
23. vasilev2015 647 28.12.16 14:56 Сейчас в теме
(22) Коллекция нужна. Дональд Кнут и Ильдарович тоже коллекции собирали )))
24. DrAku1a 1280 29.12.16 05:58 Сейчас в теме
"Аналог среза последних" - позволяет например, получить срез последних по определенному типу регистраторов, бывает нужно. Работает быстро.
"Неожиданный результат запроса" - ничего неожиданного, если помнить правило: Любое* математическое или агрегатное выражение с NULL - вернёт NULL, а любое* логическое выражение с NULL - всегда вернёт Ложь. Этим "NULL" отличается от "Неопределено".
* - Кроме двух специфичных функций ЕстьNULL() и Есть NULL, которые как раз используются для работы с NULL-значениями.

26. vasilev2015 647 29.12.16 11:38 Сейчас в теме
(24) Здравствуйте, Андрей !
Пользуюсь Вашей консолью для уничтожения вложенных запросов, спасибо.

(24)
Любое* математическое или агрегатное выражение с NULL - вернёт NULL


По поводу агрегатного выражения я тоже так думал, но посмотрите ответ (13).
29. DrAku1a 1280 30.12.16 02:56 Сейчас в теме
(26) Согласен. Насчёт агрегатных функций - 1С поступает умнее. Выходит, NULL получается только когда ВСЕ суммируемые параметры равны NULL. Интересно.
30. ADirks 179 30.12.16 08:30 Сейчас в теме
(26) А зачем уничтожать вложенные запросы? В чём профит?
31. vasilev2015 647 30.12.16 09:09 Сейчас в теме
(30) вложенные запросы не рекомендуют по новым стандартам. У меня база старая, там их много. Иногда с вложением три, четыре раза. Читать мне непривычно.
32. ADirks 179 30.12.16 09:33 Сейчас в теме
(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 сервер всё сделает как ему удобнее.
33. vasilev2015 647 30.12.16 10:17 Сейчас в теме
(32) обычно для таких случаев я использовал временные таблицы. Но возможно, есть рациональное зерно и во вложенных запросах.
34. ADirks 179 30.12.16 10:23 Сейчас в теме
(33) Временные таблицы в такой ситуации - это просто лишняя нагрузка на tempdb. Вот просто лишняя, на совершенно ровном месте.
matveev.andrey.v; +1 Ответить
36. vasilev2015 647 30.12.16 10:50 Сейчас в теме
(34) (35) И я за золотую середину ! :))
49. matveev.andrey.v 51 05.01.17 08:07 Сейчас в теме
(34) абсолютно согласен с Вами, никогда не понимал этой регилии временных таблиц, да они нужны когда используешь их в связях и когда сами таблицв очень большие, но везде их вставлять...
35. herfis 256 30.12.16 10:28 Сейчас в теме
(32) Да просто злоупотреблять вложенными запросами не стоит. Хотя многие новички эту рекомендацию воспринимают как "никогда не используйте вложенные запросы!". Нужна золотая середина. Слишком сложные моно-запросы сложнее анализировать и выше вероятность, что оптимизатор запросов может лажануть (и лечить это будет сложнее). Особенно, если кроссплатформенность интересует. В том же postgresql оптимизатор запросов менее продвинутый, чем в mssql. Во всяком случае, у меня сложилось такое впечатление. Ну, в параметрах виртуальных таблиц точно не стоит вложенные запросы использовать :)
Но если вообще избегать вложенных запросов - так это другая крайность. Сплошь и рядом это совершенно ненужная декомпозиция и по производительности тоже не айс, так как у оптимизатора не остается шансов на выбор более эффективного плана выполнения.
matveev.andrey.v; +1 Ответить
25. saudin 29.12.16 10:11 Сейчас в теме
Статья полезная. Я для себя пару запросов сохранил, чтоб не доходить "за приемлемое время в процессе работы", а просто взять и применить.
27. stol6 49 29.12.16 14:25 Сейчас в теме
"Найти документ, для которого сумма всех последующих документов меньше заданной, а сумма всех последующих документов вместе с его суммой – больше заданной.".

Что за белиберда? Из-за этого дальше и читать не хочется....
28. vasilev2015 647 29.12.16 14:54 Сейчас в теме
(27) Это дословный перевод на русский язык конструкции

ИМЕЮЩИЕ СУММА(Таб11.СуммаДокумента) < &СуммаПоследнихНеоплаченныхНакладных
И МАКСИМУМ(Таб1.СуммаДокумента) + СУММА(Таб11.СуммаДокумента) >= &СуммаПоследнихНеоплаченныхНакладных

Как сформулировать лучше ?
37. slawanix 11 03.01.17 22:26 Сейчас в теме
может и мне пора ради лайков вывесить свои абстрактные для остальных и реальные в каждом конкретном случае для себя запросы показать, вдруг кто-нибудь лайкнет.
matveev.andrey.v; +1 Ответить
40. vasilev2015 647 04.01.17 15:49 Сейчас в теме
(37) Вывешивайте, я лайкну. Или напишите - какие задачи эти запросы решают, я постараюсь их угадать и добавить к этой статье.
42. vasilev2015 647 04.01.17 16:48 Сейчас в теме
(37) Коллега, я поставил лайки на Ваши существующие статьи. Киньте мне идею: какие запросы добавить ?
47. slawanix 11 04.01.17 21:03 Сейчас в теме
(42), Николай, право, не стоило. Я же не напрашиваюсь на лайки. Просто не вижу для себя практической пользы от статьи, разве что интересным показался пример с нумерацией, чисто в учебных, опять же, целях. Согласен, кому-то статья будет полезной.
48. vasilev2015 647 04.01.17 22:03 Сейчас в теме
(47) Можете придумать, что еще в статью добавить ?
38. endym 180 04.01.17 10:49 Сейчас в теме
как по мне некоторые решения повергают меня в ступор...
1) запрос в цикле
2) передача в предусловие конструкции "Выбрать... "
3) столько статей по декартову произведению, а тут нумерацию "накопительным итогом" предлагают ;)

может для самописных мелких баз это еще сгодится, но для масштабируемых решений это погибель
39. herfis 256 04.01.17 11:19 Сейчас в теме
(38)
3) столько статей по декартову произведению, а тут нумерацию "накопительным итогом" предлагают ;)

Там по сути и есть декартово произведение. То, что условие отбора в соединении, а не в ГДЕ - непринципиально. Так просто более компактно.
Но судя по вашему снисходительному замечанию, вы можете предложить более оптимальный вариант нумерации строк в запросе. Очень хотелось бы на него посмотреть.
matveev.andrey.v; +1 Ответить
43. vasilev2015 647 04.01.17 17:19 Сейчас в теме
(39) Спасибо за хорошие слова.
45. endym 180 04.01.17 18:57 Сейчас в теме
(39)
более оптимальный вариант нумерации строк в запросе


для нумерации - СКД (служебное поле "номер по порядку")

я никоим образом не писал в снисходительном тоне.
41. vasilev2015 647 04.01.17 15:54 Сейчас в теме
Напишите ваше сообщение
(38)
1. Запрос в цикле - мне тоже неприятно. Однако процедура перепроведения документов за порождает именно запросы, именно в цикле. А здесь - красивая идея передавать временную таблицу внутрь цикла.
2. Поясните, что значит предусловие ?
3. Нумерация накопительным итогом - встречается на собеседованиях. Я предупредил.

44. endym 180 04.01.17 18:53 Сейчас в теме
(41)
1. Запрос в цикле - я бы заменил на генерацию 1 запроса из запроса-шаблона, и поиском в результате.
2. предусловие - это условие в виртуальной таблице (остатки, обороты, срез первых/последних)
3. Как для теории - решение хорошее, для высоко нагруженных систем, но как накопительный итог, а не нумерацию. нумерацию можно получить из СКД и выгрузкой/выводом на Ваше усмотрение
46. vasilev2015 647 04.01.17 20:17 Сейчас в теме
(44) 1. Бывают ситуации, когда запрос исполняется в цикле. Как правило, между выполнением таких запросов меняются данные и сделать, как Вы пишете, невозможно. Пример я приводил.
2. Про виртуальную таблицу смотрите подробнее https://its.1c.ru/db/metod8dev/content/5457. После этой статьи я понял, что лучше в условиях виртуальной таблицы делать простой запрос.
3. Нумерация мне встретилась на собеседовании, причем просили реализовать именно в запросе, без СКД. В реальной жизни не встречал.
50. dnkon 23 08.01.17 20:12 Сейчас в теме
Такой запрос с нумерацией быстрее в среднем в 2 раза на 1000 элементов.

ВЫБРАТЬ РАЗЛИЧНЫЕ
	Справочник.Ссылка КАК Ссылка,
	1 КАК Нумератор
ПОМЕСТИТЬ Таб1
ИЗ
	Справочник.Справочник КАК Справочник
;

////////////////////////////////////////////////////////////­////////////////////
ВЫБРАТЬ
	Таб1.Ссылка,
	СУММА(Таб1.Нумератор) КАК Нумератор
ИЗ
	Таб1 КАК Таб1
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Таб1 КАК Таб11
		ПО Таб1.Ссылка <= Таб11.Ссылка

СГРУППИРОВАТЬ ПО
	Таб1.Ссылка

УПОРЯДОЧИТЬ ПО
	Нумератор
Показать


51. vasilev2015 647 09.01.17 09:14 Сейчас в теме
(50) Согласен, здесь операции проще. Включу в следующую редакцию, вставлю на Вас ссылку.
58. vasilev2015 647 18.11.17 11:23 Сейчас в теме
(50) Кстати, тут слово "Различные" не нужно. При выборке из справочника ссылки будут все разные. Так еще быстрее.
52. mitia.mackarevich 28 17.11.17 09:46 Сейчас в теме
Сравнивать ссылки это эпично
53. Aleskey_K 11 17.11.17 12:17 Сейчас в теме
Если применяете сортировку в запросе, то индексировать не нужно. Обратное утверждение так же имеет силу.
55. vasilev2015 647 17.11.17 12:51 Сейчас в теме
(53) Приведите пожалуйста источник. На уровне SQL эти действия выполняются одинаковыми операторами, но вряд ли оператор сортировки сделает операцию Index Insert.
57. vasilev2015 647 18.11.17 11:19 Сейчас в теме
54. VmvLer 17.11.17 12:34 Сейчас в теме
- слишком много условностей а ля "для которых нет совпадения"..., "может/не может"

- слишком много банальных идей

- слишком много не оптимальных по производительности решений без учета громадных таблиц

Вывод - изложенные наработки хороши, но фактически бесполезны на практике
56. vasilev2015 647 18.11.17 11:16 Сейчас в теме
(54) Здравствуйте !

я математик, привык везде определять область допустимых значений, граничные условия. Как иначе ?
Почитайте Дональда Кнута. Двадцать разновидностей сортировки. Смешные названия: гномья сортировка, глупая сортировка. Банально, да ?
Оптимизация в этой теме не рассматривается, так задумано.
Все о чем написал, сам использовал. Например за год расчет остатков на каждый день использовал два раза в отчетах, один раз на собеседовании.

Напишите свою статью. Обязательно плюс поставлю.
Оставьте свое сообщение

Вакансии

Бизнес-аналитик 1С
Санкт-Петербург
зарплата от 80 000 руб. до 100 000 руб.
Полный день

Руководитель проектов по внедрению 1С документооборота
Санкт-Петербург
зарплата от 100 000 руб. до 130 000 руб.
Полный день

Руководитель по сопровождению и внедрению 1С
Санкт-Петербург
зарплата от 100 000 руб. до 120 000 руб.
Полный день

Программист 1С
Санкт-Петербург
Полный день

Ведущий специалист 1С
Москва
Полный день