Comments 4
Чрезмерное использование SQL. Стремитесь минимизировать SQL внутри алгоритма.
Доброго дня. Скажите, пожалуйста, чем применение SQL такую немилость вызвало? Ведь грамотно написанный СКЛ источник отработает быстрее, чем в цикле крутить объекты с фильтрами. Особенно если в СКЛ несколько таблиц соединено сложной логикой.
Можно как-то раскрыть эту мысль на примере?
П.С: с платформой GD знаком 3.5 года.
Добрый день! Спасибо за ваш комментарий. SQL в немилость я никоем образом не поставил. Я написал непосредственно о "чрезмерном использовании SQL". Ниже по списку укажу тезисы, которые чуть шире раскроют данную тему.
Использовать SQL внутри алгоритмов позволяют 4 функции: filterSours, queryForObjectOrNull, queryForList и script.
Все эти функции применяются в зависимости от поставленной задачи.
Их использование не запрещено (иначе зачем иметь возможность ими пользоваться).
В случае данного тезиса "чрезмерного использовании SQL", идет речь о случаях, когда c помощью функции script проставляют булево значение у логического атрибута, того же Типа объекта, что используется как базовый, что являет собой избыточность.
Также при построении алгоритма, в особенности сложных конструкций, следует не забывать об использовании Структур данных (подробнее про них тут).
Например алгоритмы не могут нативно выделить максимальную и минимальную дату, аналитик начинает использовать SQL, хотя здесь можно использовать Очередь (функция ArrayDeque).
Также если вы используете SQL, то стоит следить не только за самим синтаксисом SQL, но также не стоит забывать про индексирование полей (которые используются в блоке "where"). Аналитики часто об этом забывают.
Если речь идет об очень большом количестве данных, которые по логике должны хранится в таблицах наследованных от Примитивного объекта с суррогатным ключом (или без). И вам необходимо внутри алгоритма через цикл отфильтровать данные, то можете смело использовать filterSours.
Нельзя использовать функцию script для генерации экземпляров у Типов объектов, наследованных от таблицы Объект. Такой подход приводит к возникновению блокировок.
Аналитики не всегда осмысленно пишут SQL запросы, до такой степени, что может привести к декартовому произведению, что создает огромную нагрузку на сервер sql, от чего все запросы и пользовательские и системные встают в очередь и приложение либо не работает вообще, либо работает с большими тормозами. (Был личный опыт в разборе проблемы).
В итоге получается, если подходить разумно и с точки зрения написания алгоритма и с точки зрения написания SQL, то алгоритм будет работать быстро и без ошибок. Чрезмерное использование только SQL со временем будет приводить только к обращениям в техническую поддержку.
Кстати, про min/max даты и SQL.
Рассмотрим кейс.
Есть уникальные иденты, строковые. Назовем поле IdentObj. К примеру, "00:001", "02:0002" и т.д.
И есть данные, периодически поступающие из внешней системы. Привязанные к IdentObj. Данные пишутся в реляционную БД. Т.е. на каждое значение в IdentObj есть несколько записей в СКЛ таблице, с разными датами поступления.
Нужно для каждого значения идента в IdentObj выбрать свежие записи - т.е. записи с max датой поступления (в столбце enterdate) в разрезе каждого IdentObj.
Далее полученную выборку можно обогатить данные сцеплением связанных таблиц и т.д.
Вопрос - как получить такую выборку без SQL в GD?
Видится, что в алгоритме придется вытягивать ВСЕ записи из СКЛ таблицы (что уже плохая идея). Создать объект типа HashMap, в котором ключом будет значение Идента из IdentObj, а в Value сохранять max дату. И еще куда-то нужно сохранять данные полей datacol1, datacol2 и пр.
В SQL задача выборки решается относительно несложным запросом, с парой табличных выражений:
ООП и ФП глазами аналитика