ГС
но и не могу работать с данными напрямую так как их много
я сделал под свои нужды вот такую архитектуру орм, посмотрите
https://drive.google.com/file/d/1y13L2EiD3dHN2-W8XSNDDjqiupvEwgil/view?usp=sharing
Size: a a a
2021 July 29
HH
Выглядит мощно)) Мало, что понятно правда без кода.
Я бы не стал усложнять. Надо SQL писать и обходится без ORM - сделай запросы более менее понятными, оберни в функции с нормальным доменным неймингом.
А то такое штуки вроде должны что-то разделить, чтобы упростить понимание системы. А на деле только усложняют
Я бы не стал усложнять. Надо SQL писать и обходится без ORM - сделай запросы более менее понятными, оберни в функции с нормальным доменным неймингом.
А то такое штуки вроде должны что-то разделить, чтобы упростить понимание системы. А на деле только усложняют
A
А есть люди которые считают что бизнес логику надо прямо в бд писать в сохранённых функциях, нет тут каких-то правил, к счастью ли, к сожалению ли
SP
ну логика в базе - оч удобно когда логика работает с большим объемом данных. Дата локалити все дела
SP
просто все это можно сильно по разному делать
YG
Что думаете об sql json подходе?
https://blog.jooq.org/2019/11/13/stop-mapping-stuff-in-your-middleware-use-sqls-xml-or-json-operators-instead/
На сколько это все хрупко? Например если json перестанет быть модным? Какие “подводные камни“. Мб кто сейчас юзает подобное?
https://blog.jooq.org/2019/11/13/stop-mapping-stuff-in-your-middleware-use-sqls-xml-or-json-operators-instead/
На сколько это все хрупко? Например если json перестанет быть модным? Какие “подводные камни“. Мб кто сейчас юзает подобное?
LC
Прекрасное решение - запихнуть слой представления в слой базы данных. Это видимо какой-то дба придумал после того как сложил в бд всю бизнес логику
АГ
некоторые данные удобнее и дешевле хранить так, чем нормализовать
YG
Стоит ли называть выборки - бизнес-логикой?)
YG
Я больше про read часть.
Write часть пусть будет ORM
Write часть пусть будет ORM
LC
Ну про бизнес логику я от себя добавил, но если я правильно понял, автор сразу предлагает json на выдачу формировать в sql реквесте. В крайних случаях можно если у нас какой-то простенький рест. Но тогда может вообще лучше взять не sql server, а какую-то монгу
YG
Ты правильно понял. Но ты говоришь, что это гавно, не объясняя почему
YG
Почему не подходит для “сложненького реста”?)
LC
Не, я не хотел сказать что это говно, я хотел намекнуть что это весьма специфическое решение не для широкого применения
YG
Почему?
LC
Всегда надо думать о потенциальных изменениях требований и сколько времени займет реализация этих изменений. Что будет удобнее править? Простенький маппер или sql реквест? Вопрос ситуативный, как и решение
SP
в целом нормальная тема, чеб нет
SP
а в чем сложность мигрировать функцию или там вьюшку в базе?
SP
сложности обычно с процедурами тригерами, это не предлагается как бы