Да ладно! Я бы поверил, если бы сам на t-sql не писал) Даже от дублирования FORMAT в MonthlyCategoryRevenue нет хорошего способа избавиться, а когда пойдут условия в логике, тогда вообще гасите свет.
Но это же не t-sql, а plain sql. В любом случае, как вы это отлаживаете и потом поддерживаете? Что будете делать, если бизнес-логика выйдет за пределы аналитических функций?
Просто T-SQL это специализированный язык работы с данными, его возможности существенно шире и глубже, чем C# и соответственно без использования T-SQL для компонентов бизнес-логики весь потенциал MSSQL задействовать невозможно.
Пожалуйста, можете привести конкретный пример. Преимущество t-sql может быть в технических моментах, так как он просто ближе к бд, но чтобы было преимущество в описании бизнес-логики, ни разу не встречал.
Всё-таки F# выглядит, как полигон для обкатки концепций, которые могут в будущем попасть в C#. Если в 2010 действительно было интересно посмотреть, что там есть эдакого, то сейчас такого желания уже нет.
Исключения они на то и исключения, что случаются в исключительных ситуациях. Если их делать частью контракта, то это уже будут ожидаемые ситуации, которые лучше обрабатывать другими механизмами, через тот же Try паттерн.
Для таких ситуаций и есть иерархия исключений с корневым типом на все оставшиеся случаи жизни.
когда писал на джаве, кроме вопроса "зачем?!" по их поводу у меня не было. хорошо, что у авторов шарпа возник такой же вопрос :)
В metadata описание столбцов, в rows непосредственно данные. Как postgres отдаст такой json? Застримит или сначала полностью сформирует и только потом отдаст клиенту?
Куда ни глянь: Model.objects.query()
Куда не глянь везде select * :)
Одно дело дернуть один единственный кортеж и из него одно единственное поле, и другое дело лопатить много кортежей, каждый из которых тянуть с сервера, восстанавливать в приложении
Не думаю, что именно сериализация и мапинг добавит существенные задержки. С выборкой не сравнивал, но со вставкой был опыт с json в 3 гига, данные из которого надо было просадить в ms sql: базовики смогли это сделать за 20 минут, у меня на dotnet при помощи стандартного парсера и библиотеки linq2db получилось 2 минуты, при этом в программе не было ни строчки sql. Понятно, что в постгресе результаты могут быть другие, но это всё к тому, что нельзя безоговорочно утверждать, что в базе всегда быстрее.
это можно использовать, если надо вернуть просто список строк вернуть. если протокол будет сложнее, то не уверен, что бд эффективно сможет сформировать ответ.
из базы не дергаются поля, которые не нужны (чего ORM не умеет, если в лоб)
не знаю orm, который не умел бы делать проекции.
всяко быстрее, чем то же самое у, например, питона.
а у питона под капотом json не тот же си работает? про питон мало что знаю, но в dotnet сериализатор json очень быстрый.
Например, EF Core для SQL Server операцию Contains не транслирует в IN напрямую, а использует JSON, так как это быстрее и снимает ограничение на кол-во параметров. Также Insert и Update транслируется в Merge. Много ли разработчиков будут использовать JSON в сырых SQL или писать Merge вместо Insert и Update?
Ну да, у ORM многое зависит от качества провайдера БД и часто надо знать, во что он преобразует запрос, это наверное один из немногих минусов. Но с другой стороны ORM может сделать для запроса и оптимизацию, которую руками в SQL никогда не напишешь.
Понял, в статье другой плагин: Database Navigator это не Database Tools and SQL :) Последний как раз и идет в платной версии и отдельно похоже не распространяется.
Такой ответ ничем не лучше, чем ответ в стиле "RTFM". Ни по смыслу, ни по сетевому этикету. Интересен конкретный опыт, а не то что "придумает" сетка.
А кто спорит? Только это был комментарий на утверждение:
У ef core нет интерфейса к BulkCopy, если только не спуститься на уровень Ado.Net.
Да ладно! Я бы поверил, если бы сам на t-sql не писал) Даже от дублирования
FORMATвMonthlyCategoryRevenueнет хорошего способа избавиться, а когда пойдут условия в логике, тогда вообще гасите свет.Но это же не t-sql, а plain sql. В любом случае, как вы это отлаживаете и потом поддерживаете? Что будете делать, если бизнес-логика выйдет за пределы аналитических функций?
Но например BulkCopy в linq2db намного удобнее и универсальнее.
Пожалуйста, можете привести конкретный пример. Преимущество t-sql может быть в технических моментах, так как он просто ближе к бд, но чтобы было преимущество в описании бизнес-логики, ни разу не встречал.
Не совсем понял из статьи, на скольки одновременных подключениях проводилось тестирование.
А ваша схема подобные запросы вытащит? Верится с трудом, как правило eav будет в несколько раз медленнее классической реляционной схемой.
Так к гадалке не ходи, обычные таблицы будут быстрее. И простора для оптимизации будет больше.
Всё-таки F# выглядит, как полигон для обкатки концепций, которые могут в будущем попасть в C#. Если в 2010 действительно было интересно посмотреть, что там есть эдакого, то сейчас такого желания уже нет.
Исключения они на то и исключения, что случаются в исключительных ситуациях. Если их делать частью контракта, то это уже будут ожидаемые ситуации, которые лучше обрабатывать другими механизмами, через тот же Try паттерн.
когда писал на джаве, кроме вопроса "зачем?!" по их поводу у меня не было. хорошо, что у авторов шарпа возник такой же вопрос :)
но остальные тесты показательны: генерация запроса и маппинг практически не влияют на скорость получения результата.
И какие требования за эти деньги? Больше разработки или менеджмента?
В metadata описание столбцов, в rows непосредственно данные. Как postgres отдаст такой json? Застримит или сначала полностью сформирует и только потом отдаст клиенту?
Куда не глянь везде
select *:)Не думаю, что именно сериализация и мапинг добавит существенные задержки. С выборкой не сравнивал, но со вставкой был опыт с json в 3 гига, данные из которого надо было просадить в ms sql: базовики смогли это сделать за 20 минут, у меня на dotnet при помощи стандартного парсера и библиотеки linq2db получилось 2 минуты, при этом в программе не было ни строчки sql. Понятно, что в постгресе результаты могут быть другие, но это всё к тому, что нельзя безоговорочно утверждать, что в базе всегда быстрее.
это можно использовать, если надо вернуть просто список строк вернуть. если протокол будет сложнее, то не уверен, что бд эффективно сможет сформировать ответ.
не знаю orm, который не умел бы делать проекции.
а у питона под капотом json не тот же си работает? про питон мало что знаю, но в dotnet сериализатор json очень быстрый.
Например, EF Core для SQL Server операцию Contains не транслирует в IN напрямую, а использует JSON, так как это быстрее и снимает ограничение на кол-во параметров. Также Insert и Update транслируется в Merge. Много ли разработчиков будут использовать JSON в сырых SQL или писать Merge вместо Insert и Update?
Ну да, у ORM многое зависит от качества провайдера БД и часто надо знать, во что он преобразует запрос, это наверное один из немногих минусов. Но с другой стороны ORM может сделать для запроса и оптимизацию, которую руками в SQL никогда не напишешь.
При этом дельфевому SQL Builder вы почему-то доверяете :)
Я имел в виду SQL Builder, который внезапно появился в вашем коментарии. Это уже функциональность ORM, вы же теряете контроль за формированием SQL :)
Понял, в статье другой плагин: Database Navigator это не Database Tools and SQL :) Последний как раз и идет в платной версии и отдельно похоже не распространяется.