|
0 / 0 / 1
Регистрация: 27.06.2013
Сообщений: 88
|
|||||||||||
JSON запросы - насколько эффективны17.03.2025, 10:53. Показов 1353. Ответов 6
Метки нет (Все метки)
Здравствуйте ребята. Я хотела спросить у вас совета и послушать мнения опытных программистов.
В MSSQL есть возможность вернуть результаты запроса в виде JSON. Мне это очень понравилось. Так как мне удобно получить такой json и десерилизовать его в нужный объект. Т.е. получается мне возвращается в ответ json строка и я её десерелизую в объект на C#. Приведу маленький пример кода:
У нас в проекте использовался немного другой подход. Разные способы мы использовали. Другому программисту почему-то не очень понравилась моя идея. Он видит здесь излишенюю нагрузку на то что данные сначала серелизовались потом десерилизовались. Возможно это и так. Но если писать запрос по-другому, то придётся скорее всего использовать операторы group by, order by. И вот я не знаю что было бы наилучшим решением ? Я так же услышала что смутило что я сразу получила из БД данные в одну модель и эту же самую модель вернула в react. А другой программист больше любит делать по-другому. Он очень любит EntityFramework CodeFirst. И старается получить данные в основном посредством него. Я заметила что в запросах используется много Include вызовов, это по сути join на таблицу. И получается что мы получаем объект таблицы из БД (класс который мы создавали в code first под таблицу), далее передаём её некоторой фабрики, которая через разные связи в объектах пытается получить нужные оставшиеся данные. Т.е. мы всё равно посылаем запросы к БД на получение данных, пусть даже и через Entity Framewrok. И вот я хотела бы почитать мнения опытных разработчиков. Есть и ещё вопрос, на который хотелось бы тоже послушать мнения. Я работала как-то над большим проектом в команде. Я помню что там тоже любили entity framework code firsrt. Но потом постепенно ушли от подхода code first к подходу database first. Мы писали много хранимых процедур, у нас были тригерры на таблицах. И работало с нами несколько человек именно программистов баз данных. И вот я как-то в голове себе уложила, что база данных очень серьезная вещь в проекте, и когда нам важны там данные, т.е. мы не можем позволить себе её удалять и пересоздавать заново, то подход databae first мне нравится больше. Мне нравится когда мы не полагаемся на то как за нас entity framework организует данные, не работаем как бы с БД с закрытыми глазами, а сами продумываем схему таблиц, связи, как мы и что будем хранить. Мне понравилось когда мы стараемся хранимыми процедурами получить как можно больше данных чтобы потом не получать их через коллекции и другие связанные таблицы в коде C# уже. Мне кажется что СУДБ очень серьезная вещь в проекте и лучше чтобы мы хорошо знали как она работает, как что устроено, как грамотно и оптимально писать SQL-запросы. Я как-то не могу положиться на то что за меня код напишет лучше библиотека entity framework. Я люблю подумать, поанализировать как лучше получить данные. И мне даже понравилось что можно получить данные в json и без фабрик передать эту же модель в react. Потому как моя модель не сущность таблицы в БД. И я избегаю лишних как мне кажется моделей данных. Но меня часто убеждают что подход code first самый лучший и что можно не задумываться как там запросы пишутся им, что это крутая библиотека и можно на неё положиться. Мне кажется что подход code first больше придуман для тех кто почти ничего не знает о базах данных и совсем не владеет SQL, и плюс к этому ему не важно, если его БД удалится и будет пересоздаваться. Как бы данные в БД для него не на первом месте и потеря их не критична. Мне бы хотелось послушать мнения по поводу подходов code first и database first. Напоследок приведу мой запрос к БД, который возвращает данные в виде json:
0
|
|||||||||||
| 17.03.2025, 10:53 | |
|
Ответы с готовыми решениями:
6
Вывести запрос в формате json Запрос, получение элементов массива из JSON Вернуть запрос из базы данных в формате json |
|
14114 / 9331 / 1350
Регистрация: 21.01.2016
Сообщений: 35,064
|
||
| 17.03.2025, 10:57 | ||
|
0
|
||
|
0 / 0 / 1
Регистрация: 27.06.2013
Сообщений: 88
|
|
| 17.03.2025, 11:22 [ТС] | |
|
там не совсем все поля подогнаны под UI, есть ещё 3-4 поля которые нужно обработать и записать туда значения нужные.
Вот я их обрабатываю и возвращаю эту модель в UI. Можно правда и на UI сделать эту обработку полей. Вы думаете это хорошо будет ? Почему-то другого программиста очень смущает что я данные сразу в UI отдаю... он говорит что это не очень правильно...
0
|
|
|
14114 / 9331 / 1350
Регистрация: 21.01.2016
Сообщений: 35,064
|
|
| 17.03.2025, 11:49 | |
|
tiny developer, ну тогда это действительно выглядит избыточно. Лишняя работа для базы.
Основный смысл сего действия в чём? В удобной материализации выборки? Если так, то почему бы не использовать какой-нибудь Dapper?
0
|
|
|
0 / 0 / 1
Регистрация: 27.06.2013
Сообщений: 88
|
|
| 17.03.2025, 13:38 [ТС] | |
|
Dapper как я прочитала это аналогичная библиотека как entity framework. Но у меня есть небольшой вопрос.
Ведь библиотека получив результат запроса, тоже выполняет какую-то его обработку чтобы представить его нам в виде того объекта который мы хотим получить и передаём в качестве шаблона. Это тоже некоторая работа, как например и десерелизация результат json в объект. Не является ли всё это очень похожей работой ? Не совсем понимаю до конца, почему лишняя работа для БД ? Ведь Dapper или entity framework так же посылают внутренние запросы к БД когда вы запрашиваете данные связанных таблиц, коллекций и виртуальных полей. Вы просто этого не видите как SQL-код, за вас это делает автоматически библиотека. И я не понимаю до конца в чём преимущества ? В удобстве или привычке программиста ?
0
|
|
|
1304 / 358 / 97
Регистрация: 14.10.2022
Сообщений: 1,087
|
|||
| 17.03.2025, 15:29 | |||
|
По моему мнению, подход code first полностью и абсолютно неработоспособен, как только ваши данные становятся хоть сколько-нибудь велики. Экстремальный пример: когда у вас, в основных таблицах уже пара-тройка миллиардов записей, иногда приходится сурово поднапрячься, чтобы даже простые запросы хоть как-то работали. Докапываться до нюансов. Разумеется, entity framework очень сильно подрос за истекшие 10 лет, с т.з. оптимальности генерации запросов к БД, но, опять же, на мой взгляд, до сих пор не предназначена для оперирования данными, хоть со сколько-нибудь отличными от 0 объемами. И, кстати, проектам, написанным в подходе code first очень трудно (не буду писать - невозможно, "очень трудно") помочь при возникающих проблемах с производительностью DBA-шными методами. По крайней мере, проблемы DBAшников вырастают на пару порядков. Разумеется, опять же оговариваюсь, если речь идет о сколь-нибудь заметном объеме данных хранящихся в БД и сколь-нибудь отличном от 0 количестве сущностей, описанных в БД. Мой личный опыт показывает, что там, где ожидается больше 100 млн. записей в основных таблицах, и количество сущностей переваливает за пару-тройку сотен - возможен только database first подход, иначе проблемы производительности не удается решить никаким силами. Но, опять же хочу сказать, что всё сильно шагнуло вперед, возможно уже миллиард/тысячу переварит. Ко второму: У него есть очень большой недостаток: его Да и написание кода на стороне БД тоже становится несколько сложнее (хотя, не принципиально). В смысле сопровождения программистом (не DBA, а именно программописателем) - лучше уж возня с энтити фреймворк. Этот подход, по крайней мере, более контролируем и подвержен общим правилам и типовым решениям. На мой взгляд - это паллиатив code first подхода, который хуже и классического code first и классического database first, с запросами-хранимками, возвращающими классические наборы записей (которые да, потом приходится оборачивать отдельным слоем абстракции). В общем, для наколенных поделок - энтити фреймфорк, для сурового энтерпрайза - только хардкор, классические ХП и все манипуляции данными средствами SQL-сервера, а за попытку вернуть на клиента/в приложение что-нибудь массивнее 10 записей - расстрел на месте. Только так, только хардкор! ... Флейма для, конечно... :-))))
1
|
|||
|
14114 / 9331 / 1350
Регистрация: 21.01.2016
Сообщений: 35,064
|
|||
| 17.03.2025, 15:41 | |||
|
На EF можно писать более-менее хорошие запросы на чтение. Но сама Microsoft в своей документации этому не учит. Поэтому тут фанатизма не надо) Надо уметь пользоваться инструментом)
1
|
|||
| 17.03.2025, 15:41 | |
|
Помогаю со студенческими работами здесь
7
Аналитический запрос для определения эффективности рассылок
Запрос, который из строк преобразует в json и обратно Насколько эффективны онлайн курсы? JSON запросы на https url Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
сукцессия микоризы: основная теория в виде двух уравнений.
anaschu 11.01.2026
https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/
|
WordPad для Windows 11
Jel 10.01.2026
WordPad для Windows 11
— это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .
|
Classic Notepad for Windows 11
Jel 10.01.2026
Old Classic Notepad for Windows 11
Приложение для Windows 11, позволяющее пользователям вернуть классическую версию текстового редактора «Блокнот» из Windows 10. Программа предоставляет более. . .
|
Почему дизайн решает?
Neotwalker 09.01.2026
В современном мире, где конкуренция за внимание потребителя достигла пика, дизайн становится мощным инструментом для успеха бренда. Это не просто красивый внешний вид продукта или сайта — это. . .
|
|
Модель микоризы: классовый агентный подход 3
anaschu 06.01.2026
aa0a7f55b50dd51c5ec569d2d10c54f6/
O1rJuneU_ls
https:/ / vkvideo. ru/ video-115721503_456239114
|
Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR
ФедосеевПавел 06.01.2026
Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR
ВВЕДЕНИЕ
Введу сокращения:
аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .
|
Модель микоризы: классовый агентный подход 2
anaschu 06.01.2026
репозиторий https:/ / github. com/ shumilovas/ fungi
ветка по-частям.
коммит Create переделка под биомассу. txt
вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .
|
Расчёт токов в цепи постоянного тока
igorrr37 05.01.2026
/ *
Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях.
Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её.
Последовательность действий:. . .
|