GS
Орм маст хев, если у вас сложные запросы в sql, то стои переосмыслить логику проэкта
ОРМ ведь не запрещает отдельные сложные запросы просто билдером собирать
Size: a a a
2019 November 22
Ð
Потом окажется, что такого собирающего кода куча, придётся делать абстракцию/либу, потом её развивать и поддерживать, в итоге появится ОРМ, только сырая и неудобная)
не оказалось пока что
GS
Орм маст хев, если у вас сложные запросы в sql, то стои переосмыслить логику проэкта
А если все запросы очень простые, то подумать, а нужна ли реляционная бд)
YZ
ОРМ ведь не запрещает отдельные сложные запросы просто билдером собирать
Да, но обычно контр аргументом приводят неоптимизированые запросы, типо падает скорость. Крупные проэкты без орм видел только в пхп
YZ
Самому писать = костыли
Ð
А если все запросы очень простые, то подумать, а нужна ли реляционная бд)
вот да, удваиваю тезис. Данными занимается субд, как и положено субд, а нода - быстрый и удобный способ собрать и отрендерить из них страницу, или сделать mq/rest api
YZ
Перекладыввать логику на sql, это увиличивать время поддержки
Ð
Перекладыввать логику на sql, это увиличивать время поддержки
за примерно 8 лет как мы стали делать так, поддержка и цикл разработки значительно сократились
YZ
То вы других проэктов не видели
GS
Перекладыввать логику на sql, это увиличивать время поддержки
Смотря что считать логикой.
Одно дело — это перекидывать в ХП / триггеры логику.
Другое — перекидывать в транзации / поддержание косистентности и прочее, что дают РБД
Одно дело — это перекидывать в ХП / триггеры логику.
Другое — перекидывать в транзации / поддержание косистентности и прочее, что дают РБД
YZ
Смотря что считать логикой.
Одно дело — это перекидывать в ХП / триггеры логику.
Другое — перекидывать в транзации / поддержание косистентности и прочее, что дают РБД
Одно дело — это перекидывать в ХП / триггеры логику.
Другое — перекидывать в транзации / поддержание косистентности и прочее, что дают РБД
Я про первое, тригеры, агрегации с подсчетами, фильтрация на агрегациях и прочее
Ð
Смотря что считать логикой.
Одно дело — это перекидывать в ХП / триггеры логику.
Другое — перекидывать в транзации / поддержание косистентности и прочее, что дают РБД
Одно дело — это перекидывать в ХП / триггеры логику.
Другое — перекидывать в транзации / поддержание косистентности и прочее, что дают РБД
и то и другое, в триггерах нет ничего плохого, они помогают денонмализовать и оптимизировать данные, например делать служебные агрегатные таблицы. При этом становится совершенно не важно, что у тебя является клиентом базы, нода, пхп или терминал. Данные всегда целостны.
GS
Я про первое, тригеры, агрегации с подсчетами, фильтрация на агрегациях и прочее
Вот такое всё кажется боль просто из сложности поддержи и необходимости миграции на каждый чих
YZ
В общем, мне в проэкте орм кажеться маст0ев, много упрощает
YZ
Что сиквалайз, что тайпорм показали себя адекватно, сиквалайз немного лучше
Ð
Вот такое всё кажется боль просто из сложности поддержи и необходимости миграции на каждый чих
миграцию тебе в любом случае делать, орм или не орм
GS
Ð
миграцию тебе в любом случае делать, орм или не орм
Нет, если логику писать в приложении, то всё хранится в файлах.
Если эту логику переносить в ХП и триггеры, то я не могу их просто сделать, мне нужны миграции.
речь не про изменение структуры бд
Если эту логику переносить в ХП и триггеры, то я не могу их просто сделать, мне нужны миграции.
речь не про изменение структуры бд
Ð
а, ты про пересоздание хранимок для триггеров? это что ли сложно?
Ð
это вообще делается одним щелчком даже без даунтайма
Ð
но да, такой подход требует пересмотреть свое отношение к стеку, потому что скл становится основной частью, а сервер приложения - вторичной. И специалисты нужны немного другие. Но выхлоп стоит того, особенно радует скорость введения новой функциональности, минимум велосипедов, мертвого кода и прочего рака, легко вводить новых людей, особенно на уровень выше бд.