"Используем bind переменные с 2001 года" (tm) :) Поэтому очень странно видеть, что вы хотите еще и автоматическое экранирование идентификаторов. Если такое реализовать на t-строках, то это уже будет не sql для вашей БД, а отдельный dsl.
Хотя бы по той причине, что в запросе вокруг переменной стоят кавычки.
В статье пример для f-строк. Для t-строк кавычки должны быть убраны. Если это не так, то тоже хотелось бы увидеть комментарий автора :)
Изменение sort_column это уже изменение запроса, а не его параметризация. Не знаю ни одной библиотеки доступа к БД с "сырым" sql, которая работала бы на уровне DML. Для такой задачи нужен ORM или SqlBuilder.
Своих миграций у linq2db нет, насколько мне известно. Но никто не мешает использовать другие средства. Я использую ef core, как основной орм, linq2db как вспомогательный, в основном как раз для bulk copy. При этом linq2db строит свои модели на основе DbContext, у него это штатная функциональность.
Да ладно! Я бы поверил, если бы сам на t-sql не писал) Даже от дублирования FORMAT в MonthlyCategoryRevenue нет хорошего способа избавиться, а когда пойдут условия в логике, тогда вообще гасите свет.
Но это же не t-sql, а plain sql. В любом случае, как вы это отлаживаете и потом поддерживаете? Что будете делать, если бизнес-логика выйдет за пределы аналитических функций?
Просто T-SQL это специализированный язык работы с данными, его возможности существенно шире и глубже, чем C# и соответственно без использования T-SQL для компонентов бизнес-логики весь потенциал MSSQL задействовать невозможно.
Пожалуйста, можете привести конкретный пример. Преимущество t-sql может быть в технических моментах, так как он просто ближе к бд, но чтобы было преимущество в описании бизнес-логики, ни разу не встречал.
Плохой пример:
CalculationResult
слишком общее название, чтобы понять, что с ним можно сделать. Ничем не лучшеvar
:)У него оказывается и поддержка идентификаторов есть) Но как я понимаю, это нестандартная вещь для Python Database API.
"Используем bind переменные с 2001 года" (tm) :) Поэтому очень странно видеть, что вы хотите еще и автоматическое экранирование идентификаторов. Если такое реализовать на t-строках, то это уже будет не sql для вашей БД, а отдельный dsl.
В статье пример для f-строк. Для t-строк кавычки должны быть убраны. Если это не так, то тоже хотелось бы увидеть комментарий автора :)
Это кто как прочитал :) В контексте запроса sql и драйвера БД экранирование это всегда про параметры (bind переменные, плейсхолдеры).
Изменение
sort_column
это уже изменение запроса, а не его параметризация. Не знаю ни одной библиотеки доступа к БД с "сырым" sql, которая работала бы на уровне DML. Для такой задачи нужен ORM или SqlBuilder.Уже давно можно говорить, что rhel от ibm :)
Не думаю, что процедуры помогли бы вашему проекту. Вы бы сейчас точно также жаловались на трехэтажные запросы и спагетти код в бд.
Своих миграций у linq2db нет, насколько мне известно. Но никто не мешает использовать другие средства. Я использую ef core, как основной орм, linq2db как вспомогательный, в основном как раз для bulk copy. При этом linq2db строит свои модели на основе DbContext, у него это штатная функциональность.
Автор статьи, автор комментария или автор документации? Про других не знаю, а если по поводу пары команд, то достаточно:
Если у дистрибутива есть docker образ, то все танцы сводятся к паре команд.
Вопрос был:
Ответа в тексте LLM нет, только нагромождение общих тезисов.
Это и есть Ado.Net. Но нет спасибо, я лучше через linq2db :)
Такой ответ ничем не лучше, чем ответ в стиле "RTFM". Ни по смыслу, ни по сетевому этикету. Интересен конкретный опыт, а не то что "придумает" сетка.
А кто спорит? Только это был комментарий на утверждение:
У ef core нет интерфейса к BulkCopy, если только не спуститься на уровень Ado.Net.
Да ладно! Я бы поверил, если бы сам на t-sql не писал) Даже от дублирования
FORMAT
вMonthlyCategoryRevenue
нет хорошего способа избавиться, а когда пойдут условия в логике, тогда вообще гасите свет.Но это же не t-sql, а plain sql. В любом случае, как вы это отлаживаете и потом поддерживаете? Что будете делать, если бизнес-логика выйдет за пределы аналитических функций?
Но например BulkCopy в linq2db намного удобнее и универсальнее.
Пожалуйста, можете привести конкретный пример. Преимущество t-sql может быть в технических моментах, так как он просто ближе к бд, но чтобы было преимущество в описании бизнес-логики, ни разу не встречал.
Не совсем понял из статьи, на скольки одновременных подключениях проводилось тестирование.
А ваша схема подобные запросы вытащит? Верится с трудом, как правило eav будет в несколько раз медленнее классической реляционной схемой.