alatalo,

пришлось гуглить, чтобы найти когда и почему я это писал. Добавил вам в сообщение ссылку на оригинал.

Вообще я сам пользуюсь embedded sql. Но считаю, что им пользоваться нужно довольно аккуратно, как и всеми другими вариантами при которых компилируется SQL не в runtime. Например теже Query в классах.

Основная причина почему, это необходимость перекомпиляции любого такого SQL при изменении в структуре данных таблицы по которой идет запрос.

И еще минус в отношении embedded sql, это громоздскость запросов, когда нужно получить более одной строки. Требуется объявлять курсор, и делать проход по курсору.

Сейчас я бы посовететовал использовать Query в первую очередь, и embedded sql только в пределах того класса с которым он связан. При наличии Query его можно вызывать из любого места в коде и в разных местах.
А если нужно сделать runtime sql, делать его с помощью %SQL.Statement

Блок А.Н.Я не понял, а в чем принципиальное отличие у %SQL.Statement?В том что у него меньше зависимость от изменения структуры данных в запрашиваемой таблице.


Блок А.Н.Но ESQL хотя бы компактен в отношении запросов с получением одной строки.



Не так уж чтобы прям совсем громоздко

Я бы не сказал, что это имеет существенное значение. Да, памяти нужно больше, но не сильно много.

doublefintТочно не помню, ebmedded отображается в статистике запросов? Можно заморозить план запроса?насчет этого не уверен

kalinkolesovalatalo,
Я пользую очень часто. Только нужно в обязательном порядке проверять SQLCODE - иначе такой запрос может вернуть мусор из кеша (ну или как там у ИС называется помойка результатов запросов)
И, конечно, только если нужна одна запись, т.е. чаще всего там TOP 1 в этом запросе - чем возиться в ембедеде с курсором, проще классово непримиримо подойти к!
В ORM https://ru.wikipedia.org/wiki/ORM давно отказались от прямого доступа к данным и SQL непосредственно.
Проще написать:
record=model.search([field='данные',field2>0],order=field)
А потом проверить
if record: данные получены
обработать их
А как там реализовать быстрый доступ к данным, пускай думают разработчики СУБД.Уважаемый kalin, я вас настоятельно прошу, прекратить назвязыватся на бан. Я могу это обеспечить.

Вы бы хоть вникли в терминологию ORM. Это общий термин для фреймворков доступа к реляционным базам данных, и реализаций много разных в том числе разных и под разные СУБД. В продуктах InterSystems тоже можно сказать что есть ORM, правда и немного иначе представлена, если для классических реляционных СУБД ORM идет верхним слоем над реляционными таблицами, то в InterSystems он параллельно над глобалами и SQL уже на его основе.

Кстати зашел я тут по ссылке из вашего профиля, и что я вам могу сказать, в мире уже давно перестатали делать настолько убогие и устаревшие дизайны. Вы же наверно не просто так ссылку там используете, так как ваших работ публичных я больше не вижу, могу оценить только это.

kalinnew.ticketbus.byпосмотрите на то как сделано в RegioJet , я этим перевозчиком одно время пользовался. Не идеально, но намного удобнее чем у вас. Русского интерфейса там конечно нет, потому что это Чехия, но английский есть. У них еще и приложение на телефоне есть.