Здравствуйте, alex_public, Вы писали:

_>Там есть чёткое подтверждение того, что предкомпилированные запросы linq2db не умеют предкомпиляцию внутри СУБД. Тебе самому то не стыдно выставлять себя на посмешище подобным ведением дискуссии? Ведь каждый читающий эту темку может просто щёлкнуть по ссылке и увидеть истину.

Ну вот я щелкнул и перечитал еще раз. Чуть выше по ветке находим такое : "

Видимо мы о чём-то разном.

Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента.

Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея."

1 явное утверждение, что БД сама делает предкомпиляцию
2 сомнения на счет Prepare

Ты это перевираешь 'предкомпилированные запросы linq2db не умеют предкомпиляцию внутри СУБД'. Ты или не понимаешь, что тебе говорят, или троллишь. Как вариант, читаешь крайне невнимательно.

Здравствуйте, Ikemefula, Вы писали:

I>Ты это перевираешь 'предкомпилированные запросы linq2db не умеют предкомпиляцию внутри СУБД'. Ты или не понимаешь, что тебе говорят, или троллишь.

Ты очень правильное слово применил — юродствует.

Здравствуйте, Serginio1, Вы писали:

_>>У тебя (и не только у тебя, но ещё и у некоторых забавных товарищей, отписавшихся после тебя) похоже какие-то проблемы с чтением. У меня вроде как вполне ясно было написано, что речь не о всех запросах в приложение, а только о статических, для которых полезна предкомпиляция. Если у тебя в приложение будут тысячи именно таких запросов, то у меня для тебя есть плохие новости об устройстве твоего приложения... )))
S> Угу и как это поможет при смене БД? А речь то шла о том, что бы держать соединение и SQLCommamd ради prepare запросов. Кстати статистика собирается и планы запросов могут меняться при работе 7*24
S> На счет статических запросах только по ID, то да там под тысячу. Если брать еще другие типа по наименованию, по коду, по номеру и дате, остатки по измерениям итд то там и десятки тысяч.
S>Ты наверное только с базами на 3 таблички работал?

Какие ещё "запросы по ID", ты вообще о чём? В данной дискуссии речь шла о вполне конкретных вещах. О предкомпилированных запросах. Если ты сейчас называешь какие-то конкретные цифры количества запросов, значит у тебя под руками находятся исходники соответствующего приложения? Ну вот подсчитай сколько там используется предкомпилированнных запросов и потом начинай высказывать свои претензии на знания. А хитрую демагогию типа подмены обсуждаемых предкомпилированных запросов на вообще запросы в приложение можешь оставить для других оппонентов — я на такое не покупаюсь. )

Здравствуйте, Serginio1, Вы писали:

_>>1. Даже если предположить, что это так и есть, то какой вывод то? ) Или тебе может привиделось, что я предлагаю использовать ассемблер в бухгалтерии? )))
_>>2. Ты в чём считаешь то массовость? ) В количестве проектов или в количестве пользователей? ) Потому как если смотреть на второе, то ситуация будет как раз обратная (эти самые задачи с миллисекундами имеются на каждом компьютере, в отличие от какой-нибудь бухгалтерии).
S> Количество проектов и количество пользователей. Ты любое предприятие возьми, там бухгалтерия это малая толика. Обычно она стоит отдельно и в неё выгружают данные. А вот все бизнес процессы коих огромное количество ведут в базах как ты называешь ERP.
S> Сразу видно, что ты теоретик

По количеству пользователей банальный медиа-проигрыватель (в котором есть и ассемблерный код и ещё много чего интересного из области низкоуровневой оптимизации) легко обходит все ERP вместе взятые. )))

Здравствуйте, Serginio1, Вы писали:

_>>Т.е. в linq2db, EF и т.п. не стоило их делать? )
S> Что не стоило? Стоит делать компиляцию в ран таййме. А вот твоя статическая идет лесом.
S>Если ты говоришь о prepare, то они и так компилятся и хранятся в кэше. А поиск идет по тексту запроса. Или ты считаешь, что поисх в Хэш таблице это и есть бутылочное горлышко по сравнению двоичного поиска в базе? Вот кстати сравнение Словаря и деревьев в конце http://rsdn.ru/article/alg/tlsd.xml

Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.

1. Да, речь была как раз о предкомпиляции в СУБД, которая априори в рантайме. Так что непонятно причём тут некая статика. Ну и насчёт Prepare ты похоже плохо представляешь о чём речь. Ты лучше читай не .net документацию, а документацию к собственно СУБД. )))
2. Даже если говорить не про предкомпиляцию в СУБД, то с чего это интересно рантайм стоит делать, а статическую нет? ) Какие обоснования то? )

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Ты про использование результатов запроса что ли? ) Ну это выглядит как-то так:
_>>

_>>for(auto row: db(select(Table.a, Table.b).from(Table).where(Table.a>10))) cout<<row.a<<'\t'<<row.b<<endl;
_>>

НС>

Хорошо что ты наконец то осознал степень своей некомпетентности в данной дискуссии. )

_>>И снова ты ничего не смог ответить по сути вопроса (обсуждались то предкомпилированные запросы, а не что-то другое, но ты подправил цитирование так, чтобы постараться скрыть это), но зато попытался перейти на личности.
НС>То есть тебе можно на личности переходить, а когда тебе это возращают в ответ, то это уже криминал? Ну ну.

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

Здравствуйте, Ikemefula, Вы писали:

_>>Там есть чёткое подтверждение того, что предкомпилированные запросы linq2db не умеют предкомпиляцию внутри СУБД. Тебе самому то не стыдно выставлять себя на посмешище подобным ведением дискуссии? Ведь каждый читающий эту темку может просто щёлкнуть по ссылке и увидеть истину.
I>Ну вот я щелкнул и перечитал еще раз. Чуть выше по ветке находим такое : "
I>

Видимо мы о чём-то разном.

I>

Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента.

I> Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея."
I>1 явное утверждение, что БД сама делает предкомпиляцию

БД не делает сама предкомпиляцию. Это бредовое высказывание. БД просто исполняет запрос и при этом дополнительно ещё пытается произвести кэширование. Я надеюсь тебе не надо объяснять разницу в работе между предкомпиляцией и кэшированием?

I>2 сомнения на счет Prepare

Сомнения были не обоснованными. Но в любом случае, даже если бы они и были обоснованными (что означало бы возможность предкомпиляции в СУБД вредной), то это не отменило бы того факта, что linq2db не умеет использовать данную возможность.

Здравствуйте, alex_public, Вы писали:

_>БД не делает сама предкомпиляцию. Это бредовое высказывание. БД просто исполняет запрос и при этом дополнительно ещё пытается произвести кэширование. Я надеюсь тебе не надо объяснять разницу в работе между предкомпиляцией и кэшированием?

Ты снова неочень понимаешь по чем пишешь.

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

Кстати по этому твое предложение клеить строки с параметрами бредово.

С другой стороны в процессе построения плана параметризованного запроса для оценки селективности используются фактические параметры. Кешируется план оптимальный именно для этих параметров.
Для разных сочетаний параметров с разной селективностью, желательно иметь разные запросы, даже если логика одинаковая.
Именно поэтому нужно динамическое построение запросов в runtime (привет linq)

Для хранимых процедур работают те же правила.

I>>2 сомнения на счет Prepare

_>Сомнения были не обоснованными. Но в любом случае, даже если бы они и были обоснованными (что означало бы возможность предкомпиляции в СУБД вредной), то это не отменило бы того факта, что linq2db не умеет использовать данную возможность.

И опять ты не понимаешь о чем пишешь.

Prepare — способ делать один и тот же запрос без передачи текста запроса.
Ты делаешь один раз prepare, а потом по handle дергаешь запрос. Снижаются только затраты на передачу запроса в базу каждый раз.

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

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


ЗЫ. Кешированием результатов запросов РСУБД не занимаются от слова вообще.

Здравствуйте, Sinclair, Вы писали:

S>Вы порете феноменальную чушь. Схема с фиксированными подключениями в большинстве случаев менее эффективна

Ну, это если совсем в лоб.


S>иначе бы все использовали именно её.

Не все, но периодически используют. Весьма удобна для переиспользования неких временных таблиц.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Нет, это у тебя проблемы со знанием предметной области. По моему опыту, в типичном ERP приложении примерно 90% запросов не содержат динамических ветвлений.

Это верно для любого более-менее большого приложения. Даже для этого сайта. Большинство запросов имеют статическую структуру (или могут быть выражены через статическую структуру + параметры).

Здравствуйте, alex_public, Вы писали:

I>>1 явное утверждение, что БД сама делает предкомпиляцию

_>БД не делает сама предкомпиляцию.

1 Например MSDN с тобой не согласен https://msdn.microsoft.com/en-us/library/cc293624.aspx
MSDN утверждает, в кеше хранится по сути только два вида объектов — compiled и execution планы. Любой запрос сначала компилириуется. Здесь, например, бд пытается сделать auto-parametrization, что бы лучше кеш использовать. Результатом получается compiled. Далее по ём генерируется execution plan. И вот он то и исполняется. С __любым__ запросом — делается поиск в кеше, если план найден, он и используется, иначе создаётся заново и только тогда выполняется.

2 Prepare — ручная оптимизация, фактически удержание execution plan в кеше SQL Server. Нужны гарантии, что SQL Server не грохнет execution plan. И то, это может и не сработать в определенных условиях. Кроме того, это все накладывает определенные ограничения — для разовых запросов не действует, коннекшн в среднем удерживается дОльше.
И вот парадокс — если SQL Server испытывает нехватку памяти, то Prepare приводит к деградации производительности, например другие планы из кеша тупо выбрасываются ради удержания текущего.

3 Теперь самое интересное — parametrized запросы уже отлично укладываются в кеш ! https://www.simple-talk.com/sql/t-sql-programming/performance-implications-of-parameterized-queries/

Итого — стоит ли вручную тыкать пальцем в кеш SQL Server ?


>Это бредовое высказывание. БД просто исполняет запрос и при этом дополнительно ещё пытается произвести кэширование. Я надеюсь тебе не надо объяснять разницу в работе между предкомпиляцией и кэшированием?

Объясни, пожалуйста, а то у тебя на всё свой уникальный взгляд. Поясни, что значит 'просто исполняет' и что же кешируется ? Желательно подробно, без юродствования в твоём духе, со ссылками на вендора DB и тд.

I>>2 сомнения на счет Prepare

_>Сомнения были не обоснованными.

Вообще то вопрос свелся к статистике использования. Ты утверждаешь что 1000 запросов это 'невероятно много' а тебе сказали 'это норма'.
У тебя было 'единичных запросы встречаются редко' а тебе сказали 'единичные запросы встречаются часто'.

Здравствуйте, alex_public, Вы писали:

_>По количеству пользователей банальный медиа-проигрыватель (в котором есть и ассемблерный код и ещё много чего интересного из области низкоуровневой оптимизации) легко обходит все ERP вместе взятые. )))

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

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Serginio1, Вы писали:

_>>>Т.е. в linq2db, EF и т.п. не стоило их делать? )
S>> Что не стоило? Стоит делать компиляцию в ран таййме. А вот твоя статическая идет лесом.
S>>Если ты говоришь о prepare, то они и так компилятся и хранятся в кэше. А поиск идет по тексту запроса. Или ты считаешь, что поисх в Хэш таблице это и есть бутылочное горлышко по сравнению двоичного поиска в базе? Вот кстати сравнение Словаря и деревьев в конце http://rsdn.ru/article/alg/tlsd.xml

Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.

_>1. Да, речь была как раз о предкомпиляции в СУБД, которая априори в рантайме. Так что непонятно причём тут некая статика. Ну и насчёт Prepare ты похоже плохо представляешь о чём речь. Ты лучше читай не .net документацию, а документацию к собственно СУБД. )))

Еще раз все запросы на стороне СУБД компилирутся и кэшируются
_>2. Даже если говорить не про предкомпиляцию в СУБД, то с чего это интересно рантайм стоит делать, а статическую нет? ) Какие обоснования то? )
То, что провайдер может меняться. Я и Ikemefula тебе уже разжевывали по нескольку раз.

Здравствуйте, alex_public, Вы писали:

обратная (эти самые задачи с миллисекундами имеются на каждом компьютере, в отличие от какой-нибудь бухгалтерии).
S>> Количество проектов и количество пользователей. Ты любое предприятие возьми, там бухгалтерия это малая толика. Обычно она стоит отдельно и в неё выгружают данные. А вот все бизнес процессы коих огромное количество ведут в базах как ты называешь ERP.
S>> Сразу видно, что ты теоретик

_>По количеству пользователей банальный медиа-проигрыватель (в котором есть и ассемблерный код и ещё много чего интересного из области низкоуровневой оптимизации) легко обходит все ERP вместе взятые. )))
То есть у тебя есть статистика? По твоему на работе люди не работают, а слушают музыку?
А вот на работе как раз они и используют различные учетные системы связанные с БД

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>Ты про использование результатов запроса что ли? ) Ну это выглядит как-то так:
_>>

_>>for(auto row: db(select(Table.a, Table.b).from(Table).where(Table.a>10))) cout<<row.a<<'\t'<<row.b<<endl;
_>>

НС>

И всё-таки, что конкретно подразумевается под "ad-hoc" типами? И как бы выглядела строчка кода выше, если бы они были (ты ведь считаешь что их нет)?

Здравствуйте, gandjustas, Вы писали:

_>>БД не делает сама предкомпиляцию. Это бредовое высказывание. БД просто исполняет запрос и при этом дополнительно ещё пытается произвести кэширование. Я надеюсь тебе не надо объяснять разницу в работе между предкомпиляцией и кэшированием?
G>Ты снова неочень понимаешь по чем пишешь.
G>БД получает текст запроса, парсит, выполняет логические преобразования, потом строит план физического исполнения. Это называется компиляцией.
G>Это долгий процесс, поэтому план запроса кешируется. Это происходит всегда, если не указано дополнительных опций. Ключом является хэш строки запроса. Повторные обращения с тем же запросом не вызывают даже парсинг самого запроса.

Всё верно. Только с этим никто и не спорил.

G>Кстати по этому твое предложение клеить строки с параметрами бредово.

А вот это ты уже не прав, причём это уже обсуждалось в данной темке прямо с тобой же. Помнится ты тогда сделал для себя открытие (с помощью моей ссылки на msdn), что даже в твоём любимом SQL Server'е есть несколько разных видом кэширования: с параметрами, без параметров, с автопараметризацией.

G>С другой стороны в процессе построения плана параметризованного запроса для оценки селективности используются фактические параметры. Кешируется план оптимальный именно для этих параметров.
G>Для разных сочетаний параметров с разной селективностью, желательно иметь разные запросы, даже если логика одинаковая.
G>Именно поэтому нужно динамическое построение запросов в runtime (привет linq)

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

_>>Сомнения были не обоснованными. Но в любом случае, даже если бы они и были обоснованными (что означало бы возможность предкомпиляции в СУБД вредной), то это не отменило бы того факта, что linq2db не умеет использовать данную возможность.
G>И опять ты не понимаешь о чем пишешь.
G>Prepare — способ делать один и тот же запрос без передачи текста запроса.
G>Ты делаешь один раз prepare, а потом по handle дергаешь запрос. Снижаются только затраты на передачу запроса в базу каждый раз.

Правильно. Только плюс ещё затраты на вычисления хэша, плюс затраты на поиск в кэше, плюс затраты на повторную компиляцию, если план уже вытеснен из кэша (гарантий то нет никаких, в отличие от варианта с prepare).

G>Понятно, что prepare хорошо будет работать только если у тебя очень много одинаковых запросов. Например, при обработке датасетов в приложении и синхронизации их с базой.

Конечно. Никто и не предлагал использовать предкомпилированные запросы для всего.

G>prepare требует держать открытым соединение с базой. Если запросы появляются непредсказуемо, как в любом веб-приложении, то накладные расходы от поддержки множества соединений вместо пула превысят любой выигрыш от prepare.

Во-первых я уже тут показывал, что можно легко использовать предкомпилированные запросы и с пулом. А во-вторых я что-то пока не увидел ни одного пояснения, что же это собственно за такие накладные расходы появляются при увеличение числа соединение (скажем без пула их 20, а с пулом можно уменьшить например до 10 — и где от этого уменьшатся накладные расходы?).

G>ЗЫ. Кешированием результатов запросов РСУБД не занимаются от слова вообще.

Ну вот не надо мерить все СУБД по своему любимому SQL Server'у. Во многих СУБД данная функция включается опцией в настройках. А в некоторых даже включена по умолчанию. Правда к нашей дискуссии это прямого отношения не имеет. Разве что демонстрирует реальную компетенцию участников дискуссии.

Здравствуйте, Ночной Смотрящий, Вы писали:

_>>По количеству пользователей банальный медиа-проигрыватель (в котором есть и ассемблерный код и ещё много чего интересного из области низкоуровневой оптимизации) легко обходит все ERP вместе взятые. )))
НС>А функция, которую тут недавно один разработчик удалил из репа пакетов — гораздо чаще чем куча важных и сложных библиотек. Давайте теперь все ориентироваться на такие тупые функции.

Ты считаешь например какой-нибудь h.264 кодек тупой функцией? ) А ты уверен, что тебе по силам хотя бы просто закодировать его по готовым формулам (не разбираясь в их математическом смысле)? )))

Здравствуйте, Serginio1, Вы писали:

_>>1. Да, речь была как раз о предкомпиляции в СУБД, которая априори в рантайме. Так что непонятно причём тут некая статика. Ну и насчёт Prepare ты похоже плохо представляешь о чём речь. Ты лучше читай не .net документацию, а документацию к собственно СУБД. )))
S> Еще раз все запросы на стороне СУБД компилирутся и кэшируются

Правильно. Но даже если ты попадёшь на закэшированный запрос, то это всё равно будет менее эффективно, чем аналогичная ситуация с предкомпилированным в СУБД запросом. Если ты этого не понимаешь, то тебе следует получше разобраться с функции prepare в СУБД.

_>>2. Даже если говорить не про предкомпиляцию в СУБД, то с чего это интересно рантайм стоит делать, а статическую нет? ) Какие обоснования то? )
S> То, что провайдер может меняться. Я и Ikemefula тебе уже разжевывали по нескольку раз.

И я тебе продемонстрировал, что динамический выбор вида СУБД реализуется и при статической компиляции ровно в одну строчку (один дополнительный if на всё приложение). Так что аргументом за использование тормозной рантайм компиляции запросов это явно не является.

Здравствуйте, alex_public, Вы писали:

G>>Кстати по этому твое предложение клеить строки с параметрами бредово.

_>А вот это ты уже не прав, причём это уже обсуждалось в данной темке прямо с тобой же. Помнится ты тогда сделал для себя открытие (с помощью моей ссылки на msdn), что даже в твоём любимом SQL Server'е есть несколько разных видом кэширования: с параметрами, без параметров, с автопараметризацией.

Ты о чем вообще? Никаких разных типов кешей нет ни в одной СУБД.
Есть один кеш для всех планов и каждому запросу соотвествует один элемент в кеше, есть там параметры или нет — неважно. Про автопараметризацию забудь, она работает в таких примитивных случаях, что нет смысла обсуждать.

G>>С другой стороны в процессе построения плана параметризованного запроса для оценки селективности используются фактические параметры. Кешируется план оптимальный именно для этих параметров.
G>>Для разных сочетаний параметров с разной селективностью, желательно иметь разные запросы, даже если логика одинаковая.
G>>Именно поэтому нужно динамическое построение запросов в runtime (привет linq)

_>Опять же всё верно и опять же с этим никто собственно и не спорил. Ну не считая того, что для удобной генерации подобных динамических запросов не требуются никакие тормознутые linq.
Ты пока не смог доказать свои слова. Ты не показал ни одно средство динамической генерации запросов с удобством уровня linq.

_>>>Сомнения были не обоснованными. Но в любом случае, даже если бы они и были обоснованными (что означало бы возможность предкомпиляции в СУБД вредной), то это не отменило бы того факта, что linq2db не умеет использовать данную возможность.
G>>И опять ты не понимаешь о чем пишешь.
G>>Prepare — способ делать один и тот же запрос без передачи текста запроса.
G>>Ты делаешь один раз prepare, а потом по handle дергаешь запрос. Снижаются только затраты на передачу запроса в базу каждый раз.
_>Правильно. Только плюс ещё затраты на вычисления хэша, плюс затраты на поиск в кэше, плюс затраты на повторную компиляцию, если план уже вытеснен из кэша (гарантий то нет никаких, в отличие от варианта с prepare).
Затраты на вычисление хеша? Ты смеешься? Это один проход по строке в худшем случае.
Кеш — просто MRU, если запрос часто используется, то план будет в кеше, если редко, то prepare использовать бессмысленно.

G>>Понятно, что prepare хорошо будет работать только если у тебя очень много одинаковых запросов. Например, при обработке датасетов в приложении и синхронизации их с базой.
_>Конечно. Никто и не предлагал использовать предкомпилированные запросы для всего.
Ты как раз и предлагал. На практике у prepared запросов область применения примерно такая же, как у автопараметризации.

G>>prepare требует держать открытым соединение с базой. Если запросы появляются непредсказуемо, как в любом веб-приложении, то накладные расходы от поддержки множества соединений вместо пула превысят любой выигрыш от prepare.

_>Во-первых я уже тут показывал, что можно легко использовать предкомпилированные запросы и с пулом. А во-вторых я что-то пока не увидел ни одного пояснения, что же это собственно за такие накладные расходы появляются при увеличение числа соединение (скажем без пула их 20, а с пулом можно уменьшить например до 10 — и где от этого уменьшатся накладные расходы?).
Если бы соединения были бесплатными, то вообще идея делать пул не возникала бы.
Я проверял, 1000 открытых коннектов к SQL Server съедали около 2гб памяти на стороне БД.

С пулом количество соединений можно сократить более чем в 2 раза.


G>>ЗЫ. Кешированием результатов запросов РСУБД не занимаются от слова вообще.

_>Ну вот не надо мерить все СУБД по своему любимому SQL Server'у. Во многих СУБД данная функция включается опцией в настройках. А в некоторых даже включена по умолчанию. Правда к нашей дискуссии это прямого отношения не имеет. Разве что демонстрирует реальную компетенцию участников дискуссии.
И на практике под нагрузкой кеш на стороне базы не используется. Потому что каждый байт в кеше отнимает память для исполнения запросов, снижая быстродействие БД.
Исключения настолько редки, что не имеет смысл их рассматривать.

Здравствуйте, alex_public, Вы писали:

_>Правильно. Но даже если ты попадёшь на закэшированный запрос, то это всё равно будет менее эффективно, чем аналогичная ситуация с предкомпилированным в СУБД запросом. Если ты этого не понимаешь, то тебе следует получше разобраться с функции prepare в СУБД.
Помоему это тебе следует. Можешь тестами показать насколько prepared запросы эффективнее обычных?


_>>>2. Даже если говорить не про предкомпиляцию в СУБД, то с чего это интересно рантайм стоит делать, а статическую нет? ) Какие обоснования то? )
S>> То, что провайдер может меняться. Я и Ikemefula тебе уже разжевывали по нескольку раз.
_>И я тебе продемонстрировал, что динамический выбор вида СУБД реализуется и при статической компиляции ровно в одну строчку (один дополнительный if на всё приложение). Так что аргументом за использование тормозной рантайм компиляции запросов это явно не является.
Прости, а в каком месте этот if должен быть написан?