T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости (Переосмысление с учетом обсуждения)

Секретное оружие в .NET Core: Почему вы игнорируете мощь T-SQL? Ваши LINQ-запросы становятся громоздкими? Производительность упирается в потолок? Возможно, вы упускаете нечто важное. Эта статья — приглашение взглянуть на привычные инструменты под новым углом. Мы исследуем гибридный подход, который позволяет использовать весь потенциал Microsoft SQL Server, выходя за рамки стандартного взаимодействия через EF Core. Узнайте, как T-SQL может упростить сложные задачи, повысить производительность и сделать вашу архитектуру более гибкой. Это не просто технический трюк, а переосмысление роли СУБД в современном приложении. Готовы узнать, как использовать "скрытые" возможности MSSQL и почему это может быть именно то, что нужно вашему проекту? Читать об этом

https://habr.com/ru/articles/914378/

#net #net_core #ef #entityframework #linq #tsql #sql #mssql #mssqlserver #database_development

T-SQL в .NET Core EF Core: Гибридный подход к производительности и гибкости

В мире .NET разработки, работа с базами данных – неотъемлемая часть. Entity Framework Core (EF Core) предоставляет удобный способ взаимодействия с данными, но при работе с SQL Server, особенно в сложных сценариях, LINQ запросы могут уступать в производительности и гибкости T-SQL. Статья рассматривает эту дилемму, предлагая гибридный подход. Мы погрузимся в проблему: как эффективно использовать мощь T-SQL, не отказываясь от преимуществ EF Core? Обсудим интеграцию T-SQL через Raw SQL, Views, UDF и Stored Procedures. Раскроем лучшие практики: разделение ответственности, оптимизацию запросов, безопасность и тестирование. Поймем, как сочетать удобство ORM с производительностью SQL Server, применяя Data-Driven Design и, при необходимости, Domain-Driven Design. Статья – руководство для .NET разработчиков, стремящихся к оптимальному балансу между производительностью, гибкостью и удобством разработки при работе с SQL Server и EF Core. Читать об этом

https://habr.com/ru/articles/906522/

#net #net_core #ef #entityframework #linq #tsql #sql #mssql #mssqlserver #database_development

Как мы внедрили CockroachDB на DBaaS в компанию классических СУБД

Привет! Меня зовут Полина Кудрявцева, я

https://habr.com/ru/companies/avito/articles/854732/

#CockroachD #postgresql #postgres #cockroach_labs #dbaas #avito #базы_данных #database_development #platform_en

Хранение данных в Postgresql

В этом тексте хочется подробнее рассмотреть хранение данных в PostgreSQL на физическом уровне. Для начала определимся с общеизвестными вещами. Данные хранятся в таблицах , таблицы находятся в схемах , схемы, в свою очередь, в базах данных . Под данными я тут подразумеваю одну или несколько строк. В качестве примера будем рассматривать эталон критики, по моему личному мнению, цитаты Линуса Торвальдса. Подробнее под катом

https://habr.com/ru/articles/841674/

#sql #postgresql #database_development #базы_данных #reverseengineering

Как мы делали Low-Code конструктор для Back Office. Часть 2 (Back-End и база данных)

Привет, это вторая статья из цикла про наш путь создания Low-Code платформы-конструктора для разработки сложных Back Office систем. В прошлой статье я сформулировал, что такое «сложные системы», задачу, которую необходимо решить, а также привел набор «наблюдений» о принципах построения IT-производства на базе Low-Code инструмента. В этот раз я опишу подход, который мы выбрали для построения Back-End и работы с базой данных. В следующих статьях про принципы организации тонкого клиента.

https://habr.com/ru/articles/840946/

#lowcode_платформы #database_development #mvp #прототип #back_office #ttm #конструктор #платформа #Housekeeping #Диагностика_бд

Как мы делали low-code конструктор для Back office. Часть 1

Привет, я расскажу про наш путь создания low-code платформы-конструктора для разработки сложных Back office систем. Сложными, в данном контексте, называются продукты с базами данных на 500 таблиц и больше, тысячами web-экранов для пользователей, большим кол-вом логики в бизнес процессах, постоянным потоком новых требований и оказанием поддержки сотням клиентов. Платформой-конструктором я называю именно полноценный инструмент для создания новых (!) продуктов с нуля, а не готовый продукт с небольшими возможностями по кастомизации. Я опишу подробно историю создания нашего решения, какие подводные камни мы встретили на своем пути, и какие подходы для нас сработали лучше всего. Статья может оказаться особенно полезной для среды Финтех.

https://habr.com/ru/articles/838134/

#lowcode #platform #database_development #mvp #прототип #back_office #ttm #web_screen #конструктор_приложений #платформа

Эволюция обработки данных: от MapReduce к стриминговому движку

Yandex Query Language (YQL) — универсальный декларативный язык запросов к системам хранения и обработки данных, разработанный в Яндексе. А ещё это один из самых нагруженных сервисов: YQL ежедневно обрабатывает около 800 петабайт данных и 600 000 SQL-запросов, и эти показатели постоянно растут. Изначально YQL основывался на операциях MapReduce, которые эффективны для больших данных. Но для средних объёмов данных (до 50 Гб, которые составляют около 60% запросов) этот подход оказался неоптимальным, потому что нужно было обмениваться данными между операциями через диск. Поэтому разработчики создали новый более гибкий стриминговый движок, который значительно ускоряет обработку данных за счёт выполнения всех вычислений в памяти. В этой статье я хочу рассказать о подходах и технологиях в разработке систем для обработки данных на примере YQL. Основное внимание я уделил переходу от MapReduce к стриминговому движку, который обеспечивает более эффективную обработку данных, вмещающихся в память, и который доступен в опенсорсе.

https://habr.com/ru/companies/yandex/articles/808059/

#sql #database_development #yql #яндекс #движок #опенсорс

[Перевод] Использование Postgres-триггеров для исторических таблиц

В динамичной среде управления базами данных постоянно присутствует необходимость фиксировать и понимать изменения данных с течением времени. Начните управлять временем с использованием Postgres-триггеров, которые открывают легкий путь к сложному решению — историческим таблицам. Представьте себе мир, в котором каждое изменение вашей базы данных оставляет след, фиксирующую эволюцию ваших данных. В этом заключаются перспективы исторических таблиц — концепции, которая выходит за рамки традиционных ограничений проектирования баз данных. В этом исследовании мы углубимся во временное измерение PostgreSQL, раскроем возможности Postgres-триггеров и их ключевую роль в создании и обслуживании исторических таблиц.

https://habr.com/ru/articles/783560/

#postgres #sql #database_development #database_design #базы_данных