RN
нет конечно - в обход http stack - дергаешь router на прямую
Size: a a a
2020 July 17
.
А бд поднимается?
RN
.
Это просто e2e тесты?
RN
ну проигрываешь сценарий на api вызовах
RN
я бы назвал их functional
TP
SQL — это интерфейс к хранилищу данных, он знает внутреннюю структуру данных и отдаёт наружу данные в виде, понятном приложению.
Приложению (за пределами SQL), собственно, должно быть всё-равно, как данные организованы в базе.
Приложению (за пределами SQL), собственно, должно быть всё-равно, как данные организованы в базе.
Я скорее вот к чему. Есть допустим у меня данные, мне нужно из загрузить из базы, сделать filter, group-by, sort-by. Я могу это с одинаковым успехом в SQL-запросе или выгрузить сырые данные и сделать это же прям в коде работая с коллекцией.
Как сделать и почему?)
Как сделать и почему?)
RN
делай в sql из за перфрманса
RN
иначе всю память скушаешь
ИФ
что это за красота, научите меня вашему кунг-фу
(есть статья?)
(есть статья?)
ST
Я скорее вот к чему. Есть допустим у меня данные, мне нужно из загрузить из базы, сделать filter, group-by, sort-by. Я могу это с одинаковым успехом в SQL-запросе или выгрузить сырые данные и сделать это же прям в коде работая с коллекцией.
Как сделать и почему?)
Как сделать и почему?)
движок бд заточен на оптимизацию запросов к данным
очевидно, что если тебе нужен filter (и нигде не нужны нефильтрованные данные), то делать это в коде неоптимально со всех точек зрения
очевидно, что если тебе нужен filter (и нигде не нужны нефильтрованные данные), то делать это в коде неоптимально со всех точек зрения
IG
это сильно зависит, где лучше колбасить данные -- в базе или коде. База-то одна, а нод нацеплять можно сколько угодно.
RN
только база это в 100 раз быстрее может делать
TP
делай в sql из за перфрманса
С одной стороны перформанс, а с другой - если у пользователя переключатель сортировки? Не делать же заново запрос с другим sort-by.
Всё это наводит меня на мысль, что нужно то или иное использовать в зависимости от ситуации.
Но вот это «в зависимости от ситуации» у меня вызывает следующий диссонанс - если делать в зависмости от ситуации, то получается неконсистентно: в разным местах используются разные способы в одной кодовой базе. И подсознательно кажется что это не очень.
Или думаете это тоже какая-нибудь травма, типа как от орм?))
Всё это наводит меня на мысль, что нужно то или иное использовать в зависимости от ситуации.
Но вот это «в зависимости от ситуации» у меня вызывает следующий диссонанс - если делать в зависмости от ситуации, то получается неконсистентно: в разным местах используются разные способы в одной кодовой базе. И подсознательно кажется что это не очень.
Или думаете это тоже какая-нибудь травма, типа как от орм?))
OR
Там вообще сложная история. В оригинале там было что-то про одну причину для изменений.
RN
С одной стороны перформанс, а с другой - если у пользователя переключатель сортировки? Не делать же заново запрос с другим sort-by.
Всё это наводит меня на мысль, что нужно то или иное использовать в зависимости от ситуации.
Но вот это «в зависимости от ситуации» у меня вызывает следующий диссонанс - если делать в зависмости от ситуации, то получается неконсистентно: в разным местах используются разные способы в одной кодовой базе. И подсознательно кажется что это не очень.
Или думаете это тоже какая-нибудь травма, типа как от орм?))
Всё это наводит меня на мысль, что нужно то или иное использовать в зависимости от ситуации.
Но вот это «в зависимости от ситуации» у меня вызывает следующий диссонанс - если делать в зависмости от ситуации, то получается неконсистентно: в разным местах используются разные способы в одной кодовой базе. И подсознательно кажется что это не очень.
Или думаете это тоже какая-нибудь травма, типа как от орм?))
именно так и делать