плюсы-  это пожрать можно вволю?

ну, сейчас вроде уже догоняем, ага...

поржать, вообще-то: за анекдоты не садят, вроде.. )

диверсия!

поставил лайк статье

спасибо тебе ) у меня ридонли)

Простите, что отвлекаю от Гуриев и процессоров Эльбрус. У меня наркоманский вопрос.

Не опытен в работе с запросами из C#, java, go, поэтому хочу знать - придумали ли люди такой механизм, который крутится у меня в голове. Вот, есть вьюха. Можно ли сделать так, чтобы не нужно было писать классический

SELECT A
, B
, C
, D
from dbo.myView

 в Statement, чтобы вызывать executeQuery по нему. Есть ли какие-то готовые методы в любом из этих языков, чтобы то же самое можно было написать примерно  

SqlStatement stmt = connection.SqlStatement;
stmt.queryFrom(dbo.myView);
stmt.setColumn(A);
stmt.setColumn(D);
stmt.setColumn(C);
stmt.setColumn(D);
ResultSet rs = stmt.executeQuery

Зачем надо? Повадились гошники запросы писать свои и кидать их в мою нежную БД. Хочу дать им метод, чтобы они не писали лишних селектов и не изобретали, и не жаловались что в разных ситуациях селект разный. То есть, есть пара десятков ситуаций, где один и тот же запрос, но немного варьируется какие колонки он забирает из резалт сета. Запрос они кидают везде с одинаковым набором колонок, а забирают процентов 10 из них. Так как поля находятся в разных таблицах,  то каждый раз совершается овердофига  лишних соединений, тянутся лишние столбцы по сети, и 90%  работы (тяжёловатой) идёт впустую.
Думаю, правильно было бы сделать метод, который принимает на вход набор полей,  этот набор полей указывает в SQL запросе, и к этому же  набору полей обращается в резалт сете  — чтобы не дублировать руками их названия. Понимаю, что проще было бы эти поля по имени конкатенировать в селект, но может есть решение изящнее.

SELECT A
, B
, C
, D
from dbo.myView

SqlStatement stmt = connection.SqlStatement;
stmt.queryFrom(dbo.myView);
stmt.setColumn(A);
stmt.setColumn(D);
stmt.setColumn(C);
stmt.setColumn(D);
ResultSet rs = stmt.executeQuery

если они тупые, то ничо не поможет

а так можно сделать орм и высунуть для них только конкретные селекты

но тогда есть шанс что какой-то долбоеб сделает .ToList() сначала, а потом зафильтрует
и будет еще хуже когда террабайтная таблица на клиента поедет %)

SELECT A
, B
, C
, D
from dbo.myView

SqlStatement stmt = connection.SqlStatement;
stmt.queryFrom(dbo.myView);
stmt.setColumn(A);
stmt.setColumn(D);
stmt.setColumn(C);
stmt.setColumn(D);
ResultSet rs = stmt.executeQuery

я бы написал интерфейс на делфи для них, где уже выбирал то что закажут с конекшенов

нахрена им прямой доступ к базе

может вьюшки им сделаешь лучше?

SELECT A
, B
, C
, D
from dbo.myView

SqlStatement stmt = connection.SqlStatement;
stmt.queryFrom(dbo.myView);
stmt.setColumn(A);
stmt.setColumn(D);
stmt.setColumn(C);
stmt.setColumn(D);
ResultSet rs = stmt.executeQuery

сделай несколько методов, которые дергают соответствующий селект

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

если они один и тот же запрос запускают - то создай отдельную таблицу, в которую каждую минуту /час докидывай данные новые из этого запроса

и они пусть эту таблицу и смотрят

уже так) просто в зависимости от типа сущности в этой промежуточной таблицы, нужны разные поля в запросе => запрос немного видоизменяется на стороне го

тогда процедура возвращающая таблицу, а внутри динамический запрос

сложно поддерживать будет
Динамический запрос - это всегда весело (но не для того, кто потом его поддерживает)