Отвратительное, но рабочее решение
В отчете необходимо было добавить колонку с информацией, имеются ли настройки в табличной части основания регистратора некоего регистра или нет...
База данных маленькая, служебная. Вид деятельности (сдача в аренду нежилых помещений) ну никак не предполагает стремительного роста объема данных. В итоге позволил себе написать в запросе такой кусок:
Где Регистратор.Основание.ПоказателиОборота.НомерСтроки в (1)
Несколько разыменований, лайфках определения пуста ли таблица с помощью проверки есть ли в ней строка с номером один. В общем выглядит это ужасно. Но оно работает и обратите внимание, синтаксис почти повторяет текст задания. Да и писать это - несколько секунд. Лучше потратить время на получение основных данных, а не этого вспомогательного поля.
Через какое-то время оно к сожалению упало, когда у основания одного из регистраторов тип стал составным. Наругалось так:
Нельзя обращаться к вложенной таблице через поле составного типа
Но эта ошибка (в простом и понятном коде) очень легко обнаружилась и исправилась. Буквально за пару минут. Надо было просто привести составной тип к нужному:
Где Выразить(Регистратор.Основание Как Документ.РегистрацияДоговоровАренды).ПоказателиОборота.НомерСтроки в (1)
Даже не знаю, зачем это пишу, что и кому хочу доказать. Понятно, что надо учитывать масштабирование, рост объема данных и возможные будущие тормоза. Но на практике на нагруженных системах чаще встречаются инциденты из-за неправильной архитектуры и применения медленных алгоритмов. И это бывает у тех же авторов, которые идеально и многоэтажно (без разыменований, с кучей явных соединений) пишут запросы. Примеры:
- Дополнительный интеграционный код, хранящийся в дополнительных реквизитах (в другой таблице без индекса).
- Сервис часто отдающий объемные одинаковые данные (изменение номенклатуры и цен) сотням клиентов, вместо горизонтального масштабирования и кеширования в виде публикации готового файла.
- Падение файловых магазинных розничных баз из-за блокировок типовых планов обмена.
- Программный перебор ячеек экселевской таблицы, вместо загрузки целой области или вообще работы с CSV.
- Массовая запись в регистр сведений (сегменты номенклатуры) без использования транзакций.
Понимаете, пройдет время, выйдут новые версии 1С и СУБД, выполнение запросов с разыменованиями будет оптимизировано и ускорено, а архитектурные просчеты и медленные циклические операции так и будут приводить к деградации производительности учетных систем. Как-то так...
←37 | заметка 38