Комментарии 87
Вам, как и с гастарбайтерами, нужно обо всех них беспокоиться, серверы на MongoDB нужно обслуживать, они выходят из строя, капризничают.
А сервер posgres обслуживают единороги?
НЛО прилетело и опубликовало эту надпись здесь
Мне не очень понятно, как Cut из бэкенда и Paste во фронтенд облегчит мою жизнь
Не знаю как Вам, а вот гавнокодерам (коих, кстати, во фронтэнде почему-то собирается всегда больше, чем в бэкэнде) это точно облегчит жизнь: почти весь их ароматный продукт теперь будет кушать память и процессор не на сервере, а в браузере пользователя — больше не надо заботиться ни о памяти, ни о производительности.
НЛО прилетело и опубликовало эту надпись здесь
Пусть тогда начнут с себя и починят gmail.com
НЛО прилетело и опубликовало эту надпись здесь
И что, разрабы gmail-а и всех прочие побегут это фиксить в тот же день? Gmail, например, в первую минуту отжирает почти пол-гига оперативки, безо всяких утечек, они ещё не начались. Они это тоже пофиксят?
У меня он за день отжирает всего 200 метров. ЧЯДНТ?
Хорошо, у Вас меньше — 200 мегабайт. Вы считаете эту цифру нормальной?
НЛО прилетело и опубликовало эту надпись здесь
Потому что Thunderbird это программа на движке Mozilla Firefox.
НЛО прилетело и опубликовало эту надпись здесь
SPA, если это не единственная открытая вкладка в браузере, делит среду выполнения с другими страницами, чем повышает утилизацию ресурсов (в теории). А Thunderbird загружает браузерный движок для себя одного-любимого.
У меня есть SPA, они не жрут память как не в себя. При том, что я программист в общем-то весьма посредственный.
У меня есть SPA, они не жрут память как не в себя. При том, что я программист в общем-то весьма посредственный.
Basic HTML не умеет canned responses.
Раньше вы это обнаруживали у себя на сервере и, если это вас не устраивает, можете что-то с этим сделать.
Теперь эти тормоза будет обнаруживать у себя пользователь в браузере. И далеко не факт, что захочет сообщить об этом и пользоваться вашим ресурсом.
Теперь эти тормоза будет обнаруживать у себя пользователь в браузере. И далеко не факт, что захочет сообщить об этом и пользоваться вашим ресурсом.
О чём Вы? Большинство пользователей даже и не поймёт, какая из вкладок кушает ресурсы. Решит что надо новый ноут купить, а то это штой-то греться и тормозить стал.
Знаете, какой раньше был самый посещаемый ресурс в инете? Microsoft.com — потому что большинство пользователей не умеет настроить в IE дефолтный URL.
Знаете, какой раньше был самый посещаемый ресурс в инете? Microsoft.com — потому что большинство пользователей не умеет настроить в IE дефолтный URL.
Там же речь не о том, чтобы перенести что-то на клиента. Там речь — выкинуть самодельные реализации REST API с сервера, которые содержат тонну всякого ORM/OOP-шлака, а пользы особо давно уже не приносят, по крайней мере, в SPA-приложениях.
Ну вот пытался я как-то собрать софтину под WebAssembly этот ваш. Упёрся в лимит на 1000000 функций по достижению которых чудо-браузеры (FF, Chrome) отказываются грузить бинарник (хотя он сравнительно небольшой, 9 метров всего).
Так что вебассембле передают привет плюсовые шаблоны, которые она в приемлемых количествах жевать не умеет и в ближайшее время не собирается
Самое интересное что не просто перенос, но еще и костылями формировать безопасность каждого запроса, каждой сущности, строки БД или колонки и при этом увеличивая шанс ошибки контроля доступа в тех проектах где можно было обходиться какими-то общими практиками/фреймворками. И весь контроль доступа как-то очень низкоуровневый оказывается.
Спасибо за материал!
Только не совсем понял хронологию событий в докладе, он из прошлого(<=2016) или все же это 2018ый год?
Только не совсем понял хронологию событий в докладе, он из прошлого(<=2016) или все же это 2018ый год?
Позабавило расположение 1С на графике популярности языков.
В Силиконовой Долине
Нет, нет и нет. Вы можете сколь угодно ссылаться на то, что пошло в народ. Но на техническом ресурсе мы это не потерпим.
Год назад, я просвещал аудиторию идеологический близкой архитектурой на базе своего велосипеда — nginx модуль на bulk requests, статья Страх и ненависть в MiddleWare.
Основные категории прилетевших тапков были из следующих направлений:
Удачи в развитии!
Основные категории прилетевших тапков были из следующих направлений:
- ~50% — за регулярки — вы это обошли.
- ~50% — это неприязнь разработчиков к подобным архитектурам с логикой в базе. Возможно это вы тоже обошли — отсутствием публикации в хабе «Разработка веб-сайтов».
Удачи в развитии!
С базой тут интереснее, дело не только в хабе. Заметьте: вы предлагали использовать на любой чих хранимые процедуры или триггеры, у которых нет особых преимуществ перед обычными языками программирования, но есть куча недостатков.
Здесь же предлагается работа напрямую с таблицами в СУБД.
Здесь же предлагается работа напрямую с таблицами в СУБД.
Да — в postgrest встроены фиксированные: сериализация данных, синтаксис фильтрации столбцов и даже джоины.
Нет — postgrest не реализует прикладной логики.
Более того, вы не будете делать верификацию связей таблиц с клиента, логирование и всего того, что эффективней провернуть на стороне, которая ближе к данным, т.е. в СУБД.
И как только вам понадобиться что-то более сложное, чем просто записать или вытащить данные по элементарному условию через предлагаемый OpenAPI, вы вспомните следующую строку статьи:
И можете — это мягко сказано. В документации к OpenAPI Postgrest написано ещё конкретее:
Как бы вам не хотелось, в данной архитектуре, вы очень быстро придёте всё к тем же хранимым процедурам, за исключением сериализации данных.
Нет — postgrest не реализует прикладной логики.
Более того, вы не будете делать верификацию связей таблиц с клиента, логирование и всего того, что эффективней провернуть на стороне, которая ближе к данным, т.е. в СУБД.
И как только вам понадобиться что-то более сложное, чем просто записать или вытащить данные по элементарному условию через предлагаемый OpenAPI, вы вспомните следующую строку статьи:
Также вы можете написать хранимую процедуру и, скорее всего, если вы будете использовать PostgREST, вы будете это делать.
И можете — это мягко сказано. В документации к OpenAPI Postgrest написано ещё конкретее:
It prevents arbitrary, potentially poorly constructed and slow client queries. It’s good for quality of service, but means database administrators must create custom views and stored procedures to provide richer endpoints.
Как бы вам не хотелось, в данной архитектуре, вы очень быстро придёте всё к тем же хранимым процедурам, за исключением сериализации данных.
Или же можно просто уйти от этой архитектуры…
Как бы вам не хотелось, если у вас БД и нагрузка или сложная логика — придётся руками оптимизировать запросы. И все равно где и как они были написаны до необходимости их оптимизировать -в ORM на Java, или в клиентском коде в виде graphql или птичего query-string языка в Postgrest
из перечисленного проще всего оптимизировать традиционный бэкенд — отладчики, компиляторы, стат. типизация, тестовые фреймворки. Хранимки оптимизировать — это ужас. С другой стороны если перенести какую-нибудь примитивщину на этот самый постгрест, которую не надо дюже оптимизировать трёх этажными наговорами на SQL, то можно избавится от изрядного количества раздражающего бойлерплейта
Так оптимизация на стандартном бекенде, даже с ORM — все равно сводится к тому, чтобы он делал более эффективные SQL-запросы. Кроме БД там нечему тормозить же. Можно оптимизировать SQL-запросы на уровне ORM — и это проще, да. Но смысл-то не меняется.
Есть мнение (и не только моё), что хранимки-то как раз *гораздо* проще оптимизировать, чем ORM. Спросите любого эксперта по оптимизации SQL, что ему будет удобнее — SQL в хранимке или ActiveRectord и прочие.
А эксперт по оптимизации ORM скажет ровно обратное :-)
О как.
Я всегда с удовольствием готов изучать что-то новое.
Расскажите, что это за зверь такой.
Я всегда с удовольствием готов изучать что-то новое.
Расскажите, что это за зверь такой.
Да ровно то же самое, только в другом месте…
Какой-то не особо пока известный науке зверь получается.
А чего и как он там оптимизирует, не имея нормальных средств для диагностики (статистика, explain) и собственно оптимизации (индексы, параметры СУБД, БД и её объектов)?
НЛО прилетело и опубликовало эту надпись здесь
Уходим на второй круг. Где почитать про это можно?
НЛО прилетело и опубликовало эту надпись здесь
Вы только что описали стандартный сценарий, в котором вся идея ORM – асбтрагироваться от SQL и «ненавистной базаданщины» — сводится на нет.
Да, именно так обычно и происходит при росте нагрузки и проблемах с производительностью — SQL-лапша, созданная в недрах ORM, шевелит волосы у DBA и, чтобы снизить энтропию, запрос фиксируется или начинается нормальная работа по оптимизации. Завод по производству (ORM) со всей его дурной мощью вдруг становится не нужен, программист получает нормально отформатированный и отдаженный SQL (или хранимку! об этом я и говорил изначально — её отлаживать проще, когда нужно ехать, а не «шашечки») и вся роль этой лапшефабрики сводится к дёрганию метода query(..) или аналога, а такой метод есть и в самом драйвере вашего любимого языка к СУБД.
Есть много статей на тему «почему ORM – зло», наблюдаю их лет 15 ежегодно. Тема очень, очень и очень холиварная, но в целом сводится к тому, что лучше тратить время на изучение SQL, чем на штуку, которая позволяет якобы от него отойти.
На самом деле, если рассуждать дальше, PostgREST и подобные прокладки — в целом тоже похожее зло. Но всё же чуть меньшее, потому что:
- меньше степеней свободы (сложнее отсрелить себе ноги, используя какую-нибудь ООП-ориентированную конструкцию, трансляция GET/POST/PATCH/PUT в SQL гораздо более примитивная вещь, чем ORM),
- поощряется изучение SQL так или иначе — когда определяете вьюшки, вы испольузете SQL и это проще отлаживать,
- аналогично с хранимками, чем больше их используете, тем глубже понимаете работу БД и делаете вещи более оптимально, SQL внутри PL/pgSQL – абсолютно родное и естественное тело (
var1 := 0;– это на самом делеselect 0 into var1;. А как легко и приятно писать штуки типаif (select count(1) from blabla) > 0 then ...!).
НЛО прилетело и опубликовало эту надпись здесь
Вот не надо так категорично, далеко не все сводится на нет.
Запрос лежит вместе с исходниками и изменяется с ними же, в то время как хранимки лежат в БД и в лучшем случае изменяются миграциями. Как результат — я всегда могу сделать git blame запросу, но зачастую не могу то же самое проделать с хранимкой.
В строго типизированных языках ORM берет на себя раскладывание результатов запроса по полям структуры или объекта с контролем типа. Можно в одну строчку выполнить запрос и получить коллекцию результатов.
Если же отбросить ORM — то то же самое придется делать вручную. На сложный запрос может уйти целая страница кода только для подготовки параметров и чтения результатов… Казалось бы, причем тут оптимизация? А при том, что чем меньше кода — тем проще его менять. Главный враг оптимизации — мысли "ну вот, я щас что-нибудь поменяю — и опять все поломается".
Ваше утверждение "хранимку отлаживать проще" ничем не обосновано. И от того что вы его повторите еще пять раз — оно не станет истиной.
Точно так же ничем не обоснована эмоциональная оценка, которую вы дали разным технологиям ("ORM со всей его дурной мощью" и "нормально отформатированный и отдаженный SQL"). Я точно так же могу написать "с появлением нормальных ORM программисты получили возможность писать нормально отлаженный и отформатированный код вместо SQL со всей его дурной мощью" — и это будет ничуть не менее правдиво (и не более).
Так, стоп, стоп. Я вас узнал :-)
Отматываем чуть назад и ждём обоснований ваших прошлых утверждений. Напоминаю:
> А эксперт по оптимизации ORM скажет ровно обратное :-)
Вопрос: Я всегда с удовольствием готов изучать что-то новое.
Расскажите, что это за зверь такой.
> Да ровно то же самое, только в другом месте…
Вопрос: А чего и как он там оптимизирует, не имея нормальных средств для диагностики (статистика, explain) и собственно оптимизации (индексы, параметры СУБД, БД и её объектов)?
Отматываем чуть назад и ждём обоснований ваших прошлых утверждений. Напоминаю:
> А эксперт по оптимизации ORM скажет ровно обратное :-)
Вопрос: Я всегда с удовольствием готов изучать что-то новое.
Расскажите, что это за зверь такой.
> Да ровно то же самое, только в другом месте…
Вопрос: А чего и как он там оптимизирует, не имея нормальных средств для диагностики (статистика, explain) и собственно оптимизации (индексы, параметры СУБД, БД и её объектов)?
А кто вам сказал что нет средств для диагностики и оптимизации?
Статистику собрать несложно. Explain делается тоже довольно просто: перехватывается запрос и делается ему этот самый explain. На всякий случай уточняю: тот факт что в какой-то момент программист увидел SQL никоим образом не нарушает абстракцию.
Индексы и параметры СУБД настраиваются точно так же как и раньше: ORM абстрагирует от DML, а не от DDL.
Статистику собрать несложно. Explain делается тоже довольно просто: перехватывается запрос и делается ему этот самый explain. На всякий случай уточняю: тот факт что в какой-то момент программист увидел SQL никоим образом не нарушает абстракцию.
Индексы и параметры СУБД настраиваются точно так же как и раньше: ORM абстрагирует от DML, а не от DDL.
Вы сами и сказали только что.
Ну и осталось ещё один шаг в рассуждениях сделать, чтобы понять, что раз ORM никак не помогает в оптимизации, то она, наоборот, мешает (затрудняет доступ к реальному SQL, часто производя ту самую неотформатированную, малопредсказуемую и малоуправляемую лапшу, о которой уже была речь выше).
Думаю, тут мы уже всё прояснили и копать больше некуда.
Ну и осталось ещё один шаг в рассуждениях сделать, чтобы понять, что раз ORM никак не помогает в оптимизации, то она, наоборот, мешает (затрудняет доступ к реальному SQL, часто производя ту самую неотформатированную, малопредсказуемую и малоуправляемую лапшу, о которой уже была речь выше).
Думаю, тут мы уже всё прояснили и копать больше некуда.
В ОРМ производительность труда программистов выросла. Не все могут быть хорошим ДБА. Лучше иметь одного хорошего в команде и пусть оптимизирует запросы. А остальные быстро пишут ООП-код
Я немного неправильно выразился. Скорее «дешевле» чем «проще»
Вынуть кусок кода из ORM в хранимку, и оптимизировать там — проще, да, там сразу можно кучу фичей недоступных в ORM взять, например разбить запрос через временные таблицы, или CTE какие-нибудь взять.
Но как только это сделал — оно будет аукаться на каждом изменении схемы БД. Ну, например рефакторинги, и find usages в IDE — хранимку не видят. Поэтому оставаться в рамках ORM — дешевле в долгосрочной перспективе. Можно же прям в ORM запрос поменять, разбить на пару запросов попроще, индексы докинуть на таблички.
Вынуть кусок кода из ORM в хранимку, и оптимизировать там — проще, да, там сразу можно кучу фичей недоступных в ORM взять, например разбить запрос через временные таблицы, или CTE какие-нибудь взять.
Но как только это сделал — оно будет аукаться на каждом изменении схемы БД. Ну, например рефакторинги, и find usages в IDE — хранимку не видят. Поэтому оставаться в рамках ORM — дешевле в долгосрочной перспективе. Можно же прям в ORM запрос поменять, разбить на пару запросов попроще, индексы докинуть на таблички.
Верно. Тут ключевое даже не временные таблицы или CTE, а RTT — сетевая сложность. Хранимка даёт возможность отработать всё на сервере с использованием индексов и алгоритмов СУБД и выдать уже краткий результат без лишнего бегания туда-сюда.
Что касается рефакторинга. Мне немного сложно понять, о чём тут речь, т.к. я много лет в tmux+vi и не понимаю, о какой IDE тут речь и о каких её средствах.
Но как-то похоже на то, что подразумевается, что код хранимки — это что-то такое, что где-то там запрятано в недрах БД. Это, конечно, не так (а если так — это беда и так делать нельзя). Хранимка — это обычный код, должен быть в git, версионироваться и нормально рефакториться. Другое дело, что, может быть, «find usages» вашей IDE пока не поддерживают plpgsql (а может, поддерживают? доступные плагины смотрели?).
Что касается рефакторинга. Мне немного сложно понять, о чём тут речь, т.к. я много лет в tmux+vi и не понимаю, о какой IDE тут речь и о каких её средствах.
Но как-то похоже на то, что подразумевается, что код хранимки — это что-то такое, что где-то там запрятано в недрах БД. Это, конечно, не так (а если так — это беда и так делать нельзя). Хранимка — это обычный код, должен быть в git, версионироваться и нормально рефакториться. Другое дело, что, может быть, «find usages» вашей IDE пока не поддерживают plpgsql (а может, поддерживают? доступные плагины смотрели?).
Хранимка — это обычный код, должен быть в git, версионироваться и нормально рефакториться.
Отлично, осталось найти способ разместить его там. Так, чтобы изменения в нем автоматически применялись к БД при развертывании.
Особенно весело когда хранимка зависит от таблицы, а в таблице есть вычисляемый атрибут, который обращается к пользовательской функции. Вот как автоматически построить порядок в котором вся эта радость должна создаваться в базе, причем с учетом того что база прошлой версии уже есть и дропать ее нельзя?
Ага, «вычисляемый атрибут». MySQL? Теперь я ничего не имею против того, что вы не любите хранимки и плохо меня понимаете. Подождите ещё несколько лет, пока их, а также транзакционный DDL, недостатки поддержки целостности данных (типа stackoverflow.com/questions/2115497/check-constraint-in-mysql-is-not-working) допилят до нормального состояния. В MySQL 8 и свежих MariaDB дела с некоторыми из этих вещей уже сильно лучше, советую обновиться.
А лучше переезжайте уже на Постгрес, чтобы понять, что такое нормальные хранимки, поддержка целостности, транзакционность DDL, больше современных фич стандартного SQL.
Код каждого объекта — в отдельном файле, конечно же в git. В качестве системы миграций — sqitch.org (или другая, есть много разных со своими плюсами-минусами. Только обязательно что-то выбрать надо — ничего страшного и стыдного нет, что вы ещё это не сделали, все через это когда-то проходили). Для версионирования хорошо помогают схемы (каждая версия — в отдельной схеме). Также по этим темам полезно послушать доклады Яндекса, Авито и других крупных компаний. Много чего можно найти тут: www.youtube.com/playlist?list=PL6sRAkPwcKNnwScnpKomNXechZQ3WZe1j
А лучше переезжайте уже на Постгрес, чтобы понять, что такое нормальные хранимки, поддержка целостности, транзакционность DDL, больше современных фич стандартного SQL.
Код каждого объекта — в отдельном файле, конечно же в git. В качестве системы миграций — sqitch.org (или другая, есть много разных со своими плюсами-минусами. Только обязательно что-то выбрать надо — ничего страшного и стыдного нет, что вы ещё это не сделали, все через это когда-то проходили). Для версионирования хорошо помогают схемы (каждая версия — в отдельной схеме). Также по этим темам полезно послушать доклады Яндекса, Авито и других крупных компаний. Много чего можно найти тут: www.youtube.com/playlist?list=PL6sRAkPwcKNnwScnpKomNXechZQ3WZe1j
Да, sqitch вы можете и с MySQL использовать, он мультиплатформенный. Как и какой-нибудь более «энтерпрайзовый» liquibase.
Это ответ на вопрос «как разместить в git».
Это ответ на вопрос «как разместить в git».
Нет, не угадали, MS SQL. Кстати, его-то sqitch и не поддерживает, а я уж обрадовался…
можно глянуть flywaydb.org/documentation/database/sqlserver
Да, глянул документацию на sqitch внимательнее… К сожалению, эта штука не в состоянии сама установить зависимости между объектами базы. А значит, возможен вариант когда из-за забытой зависимости миграция сломается через два месяца и сразу на проде.
А еще пугает ее способность rebase, которая дропает из базы все данные...
Вот еще интересный вопрос. sqitch же требует revert-скрипта для любого объекта.
Как сделать revert для alter table Foo drop column Bar?
Я как-то давным-давно писал тулзу, чтобы мигрировать БД. Схема мигрировалась как обычно — дельта-скриптами и табличкой в БД чтобы знать какие скрипты уже накатили. А хранимки/функции/view — лежали на диске, по файлу на объект.
Алгоритм был такой:
— сносим все хранимки/прочие объекты с БД
— прогоняем дельта-миграции
— кладем все *.sql файлы с хранимками/вьюхами/UDF в список-очередь
— накатываем по одному объекта из списка. Если при накатывании SQL кидает ошибку — кладем в конец списка и продолжаем накатывать следующий
— если мы пробежались по кругу, и очередь не уменьшилась — кидаем все ошибки в консоль.
Таким образом обрабатывались даже нетривиальные зависимости, вроде той что ты пишешь.
Работало все отлично, шустро, и без проблем.
Было это лет 7 назад. А известной статье — blog.codinghorror.com/get-your-database-under-version-control — по мотивам которой я эту тулу и делал — уже 10 лет. С тех пор, я так и не увидел ни одной тулы для миграций БД, которая реализовала бы такой механизм. В современных тулах для миграции, хранимки предполагается класть в миграции — и это совсем тупо, да. И многие так и делают, от чего хочется плакать.
Алгоритм был такой:
— сносим все хранимки/прочие объекты с БД
— прогоняем дельта-миграции
— кладем все *.sql файлы с хранимками/вьюхами/UDF в список-очередь
— накатываем по одному объекта из списка. Если при накатывании SQL кидает ошибку — кладем в конец списка и продолжаем накатывать следующий
— если мы пробежались по кругу, и очередь не уменьшилась — кидаем все ошибки в консоль.
Таким образом обрабатывались даже нетривиальные зависимости, вроде той что ты пишешь.
Работало все отлично, шустро, и без проблем.
Было это лет 7 назад. А известной статье — blog.codinghorror.com/get-your-database-under-version-control — по мотивам которой я эту тулу и делал — уже 10 лет. С тех пор, я так и не увидел ни одной тулы для миграций БД, которая реализовала бы такой механизм. В современных тулах для миграции, хранимки предполагается класть в миграции — и это совсем тупо, да. И многие так и делают, от чего хочется плакать.
Чтобы был контекст: у меня .NET/Entity Framework, SQL Server, бизнес-приложения, нагрузка — низкая, сложность запросов — высокая (в основном — из-за сложных security-правил).
В SQL Server — совершенно убогий язык T-SQL. Я видел проекты где все на хранимках в T-SQL — там совершенный ад был.
В других раскладах, например если java, где запросы в ORM — просто строки, и есть Postgres — где человеческий встроенный язык — расклад может быть другой.
С .NET/EntityFramework, ты можешь в Visual Studio нажать правой кнопкой на поле класса, которое соответствует полю таблички, выбрать rename, ввести новое имя, и весь код гарантированно корректно поправиться. Миграция БД сделается почти автоматически.
С хранимками же — тебе надо будет руками ходить и каждую править. Файлы .sql с хранимками — они не прозрачны для IDE, она не понимает даже про какую БД они. Из удобств — только поиск по тексту. Возможно, в других БД иначе, но в SQL Server/SQL Server Management Studio — оно так.
Т.е. я не говорю что совать всю логику в хранимки — плохо. Но чтобы делать хранимки надо хороший язык в БД, хороший тулинг, нужно толковых базистов. И нужно выкидывать ORM и все делать тогда в БД. Пополам-напополам — получается шиза и бардак.
Да и в целом, код и данные должны быть близко. Для этого можно тащить код к данным (хранимки, Tarantool, и т.п.), или тащить данные ближе к коду (Datomic). А ORM — это дураций костыль, возникший от того что есть хорошие БД, но они — black box — и в них нормальный язык не всунешь, и их как библиотеку к себе код не вставишь. Думаю эта проблема решится потихоньку, и ORM вообще отсохнут со временем.
В SQL Server — совершенно убогий язык T-SQL. Я видел проекты где все на хранимках в T-SQL — там совершенный ад был.
В других раскладах, например если java, где запросы в ORM — просто строки, и есть Postgres — где человеческий встроенный язык — расклад может быть другой.
С .NET/EntityFramework, ты можешь в Visual Studio нажать правой кнопкой на поле класса, которое соответствует полю таблички, выбрать rename, ввести новое имя, и весь код гарантированно корректно поправиться. Миграция БД сделается почти автоматически.
С хранимками же — тебе надо будет руками ходить и каждую править. Файлы .sql с хранимками — они не прозрачны для IDE, она не понимает даже про какую БД они. Из удобств — только поиск по тексту. Возможно, в других БД иначе, но в SQL Server/SQL Server Management Studio — оно так.
Т.е. я не говорю что совать всю логику в хранимки — плохо. Но чтобы делать хранимки надо хороший язык в БД, хороший тулинг, нужно толковых базистов. И нужно выкидывать ORM и все делать тогда в БД. Пополам-напополам — получается шиза и бардак.
Да и в целом, код и данные должны быть близко. Для этого можно тащить код к данным (хранимки, Tarantool, и т.п.), или тащить данные ближе к коду (Datomic). А ORM — это дураций костыль, возникший от того что есть хорошие БД, но они — black box — и в них нормальный язык не всунешь, и их как библиотеку к себе код не вставишь. Думаю эта проблема решится потихоньку, и ORM вообще отсохнут со временем.
Мне вот не хватает мотивации для ORM, хотя и от написания хранимых процедур я не в восторге. Например, учёные всего мира безуспешно бьются над вопросом — как обучить ORM древовидным/рекурсивным структурам данных, которые довольно часто встречаются. Я тоже пытался — никак.
Но даже для реализации банального отношения one-to-many в ORM нужно прописывать не типизированные метаданные, просто вывести SQL запрос из класса ORM не может. Для этого надо выкурить на много больше доков по ORM, чем знание пары тройки SQL инструкций, которые она генерирует. То есть возни много, а на выходе пшик.
Миграция с переименованием полей не на столько частый рефакторинг чтобы из-за него тащить с собой EF (у меня контекст аналогичный, низкая нагрузка, сложные данные, стек другой). И тот же DataGrip в раз сделает все переименования в хранимках, в t-sql в т.ч.
Но даже для реализации банального отношения one-to-many в ORM нужно прописывать не типизированные метаданные, просто вывести SQL запрос из класса ORM не может. Для этого надо выкурить на много больше доков по ORM, чем знание пары тройки SQL инструкций, которые она генерирует. То есть возни много, а на выходе пшик.
Миграция с переименованием полей не на столько частый рефакторинг чтобы из-за него тащить с собой EF (у меня контекст аналогичный, низкая нагрузка, сложные данные, стек другой). И тот же DataGrip в раз сделает все переименования в хранимках, в t-sql в т.ч.
НЛО прилетело и опубликовало эту надпись здесь
Но даже для реализации банального отношения one-to-many в ORM нужно прописывать не типизированные метаданные, просто вывести SQL запрос из класса ORM не может.
Да ладно? Entity Framework Code First:
public class Foo
{
public long Id { get; set; }
[Required]
public Bar Bar { get; set; }
}
public class Bar
{
public long Id { get; set; }
public ICollection<Foo> Foos { get; set; }
}Все, one-to-many автоматически вывелось из этих классов! Если совсем минимизировать пример то можно даже из двух навигационных свойств оставить только одно.
Сложности возникают только когда есть несколько параллельных связей. Но даже там при желании можно сделать все типизировано.
И как только вам понадобиться что-то более сложное, чем просто записать или вытащить данные по элементарному условию через предлагаемый OpenAPI+1. Потом появляется задача вроде «если на картинке имеется кошка, то...»(или в тексте говорится про кошек) и тут вдруг оказывается, что на движке БД этого не сделать, и всё-равно нужен бэкенд.
По теме «вся логика — на плечах бд»: кажется пару лет назад проскакивала тема, что это плохая тема, что БД со временем начинает загибаться от кучи триггеров, дебажить это становится очень сложно, и всё плохо с парралелизмом. Это еще актуально?
НЛО прилетело и опубликовало эту надпись здесь
Это было актуально ещё когда многие здесь комментирующие ходили в начальную школу. Посмотрите, как реализована логика в любой АБС-ке. Код на PL/SQL не считается злом, почему он должен считататься злом на PL/pgSQL?
Крупные, очень крупные проекты не боятся хранимок. Их боится в основном те, кто в целом СУБД боится.
Крупные, очень крупные проекты не боятся хранимок. Их боится в основном те, кто в целом СУБД боится.
Ошибаетесь.
madlib.apache.org
Загибаться БД может по массе причин. В основном это монструозные бездумные запросы от ORM-ок. Хватит уже валить на хранимки и хватит их бояться.
madlib.apache.org
Загибаться БД может по массе причин. В основном это монструозные бездумные запросы от ORM-ок. Хватит уже валить на хранимки и хватит их бояться.
Думаю что многим не нравится идея хранимок в абсолютно непревзойденной убогости языка на котором они пишутся. И это плюс один-два языка (sql и tsql) в оперативный контекст работы программиста. Если была бы возможность в том же Sql Server писать сразу приложения на C# в виде набора хранимок\классов, то возможно и обсуждать было бы нечего. (про сборки знаю, но это лютый костыль)
НЛО прилетело и опубликовало эту надпись здесь
У нас аналогичный подход, правда не postgrest, а самописная проксирующая тулза. Новые методы для rest создаются написанием psql функций определённого формата.
Скорость разработки просто потрясающая.
Но, пройдя многолетний путь, мы упёрлись в производительность постгреса. Использовали все механизмы распараллеливания, но всё равно. Такой сервис довольно легко завалить умеючи.
В итоге концепцию пока сохранили, но используем программные обёртки в нашем postgrest для хитрого выборочного кэширования.
В целом концепция интересная, живая, но не без нюансов на высоконагруженных сервисах.
Скорость разработки просто потрясающая.
Но, пройдя многолетний путь, мы упёрлись в производительность постгреса. Использовали все механизмы распараллеливания, но всё равно. Такой сервис довольно легко завалить умеючи.
В итоге концепцию пока сохранили, но используем программные обёртки в нашем postgrest для хитрого выборочного кэширования.
В целом концепция интересная, живая, но не без нюансов на высоконагруженных сервисах.
«Скорость разработки просто потрясающая» — именно!
На моих глазах целая команда рубистов заменялась одним человеком, готовым писать SQL и коллекции тестов в postman/newman.
Что именно с производительностю? PostgREST ведь stateless, запускайте его на N машинах, часть из которых направляйте на read-only реплики.
Как я понимаю, проблема была в Постгресе самом? Что именно тормозило-то?
На моих глазах целая команда рубистов заменялась одним человеком, готовым писать SQL и коллекции тестов в postman/newman.
Что именно с производительностю? PostgREST ведь stateless, запускайте его на N машинах, часть из которых направляйте на read-only реплики.
Как я понимаю, проблема была в Постгресе самом? Что именно тормозило-то?
запускайте его на N машинахЕсть предположение, что 1 хорошо написанный backend может заменить N машин с обычным PostgRest. Самое первое что лезет на ум — кеширование запросов.
Плюс бесконечно добавлять N машин не получится, рано или поздно, расходы на постоянную синхронизацию огромного количества данных будут класть реплики, и нужно будет уже думать над горизонтальном масштабировании (данные пользователей от 1 до 100 лежат на серверах №1, данные пользователей 101-200 на серверах №2), и уже это будет очень сложно и трудоёмко реализовывать силами лишь PostgRest.
НЛО прилетело и опубликовало эту надпись здесь
1.1 Не понимаю почему «фронтов сейчас много» вдруг оказалось недостатком. Обычно это считается основным преимуществом…
2. Какое нафиг обновление толстого клиента и разные ОС? Ау, речь идет о веб-приложении! Главное достоинство веб-приложений — всегда актуальная версия клиента. Это работает независимо от того толстый там клиент или тонкий.
3. Вот именно, на уровне БД не должно быть никакой логики кроме контроля доступа. Тестировать отсутствующую логику очень просто, даже если это БД.
2. Какое нафиг обновление толстого клиента и разные ОС? Ау, речь идет о веб-приложении! Главное достоинство веб-приложений — всегда актуальная версия клиента. Это работает независимо от того толстый там клиент или тонкий.
3. Вот именно, на уровне БД не должно быть никакой логики кроме контроля доступа. Тестировать отсутствующую логику очень просто, даже если это БД.
(прочитал только первую строчку, на неё и реагирую)
это не я решил, а весь мир решил и уже давно. Похоже, я недостаточно ясно эту мысль донёс.
это не я решил, а весь мир решил и уже давно. Похоже, я недостаточно ясно эту мысль донёс.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
noBackend, или Как выжить в эпоху толстеющих клиентов