Спасибо за статью! Коротко и по делу. Думаю, что проблема еще в том, что изобретать велосипед иногда интересно. Но с опытом начинаешь понимать и видеть, что есть кучу других нерешенных проблем и если уж хочется приложить куда-то творческого гения, то лучше туда. Так как время конечно и всех велосипедов все равно не сделаешь. Поэтому для решенных задач нужно использовать уже готовые инструменты. Хотя для новичка это и может показаться скучным. Но как я уже сказал, если хочется творить, то лучше делать это там, где это действительно нужно. Справедливости ради, есть и плюс от велосипедостроения — это изучение чего-либо. Но даже в этом случае дальше песочницы такие решения уходить не должны.
А почему имеет смысл делать это на бэке? Я про аналитические функции. Давайте возьмем простейшее. Нужно посчитать SUM() по разным срезам и, возможно, фильтрам. Допустим где-то по месяцам разбить, а где-то по годам. Причем само отношение, которое мы будем группировать, получается путем джойна 5 таблиц. Итак, что вы будете делать в БД, а что на бэке? Мой вариант — создать вьшку, которая джойнит эти 5 таблиц, а потом обращаться к ней с разными WHERE и GROUP BY, применяя SUM(), как агрегирующую функцию. Это будет в 5 раз короче, чем то же делать на бэке. Это будет быстрее. Это будет дешевле по памяти. Это будет удобнее поддерживать. В частности это удобнее читать. А какой Ваш вариант?
Речь не только про хранимки. Например нам нужно получить некоторое аналитическое представление каких-то данных в БД. Часто вижу, что это начинает лопатиться на бэке. С аргументацией "логики в БД быть не должно". Ну начнем с того, что даже фильтр по какому-то полю относится к логике. WHERE тоже на бэке будете делать? При тщательном рассмотрении можно понять, что БД — это и есть отражение предметной области с которой вы работаете. А если это не так, то Вас ждут проблемы. Где та грань, что нельзя делать в БД? Прям реально любопытно. Сможете рассказать?
В подавляющем большинстве случаев SQL сильно лучше для обработки данных, чем Python. Так что я прекрасно могу понять желание перенести все эти расчеты в БД. А если разработчик выучил Python и теперь пытается использовать его везде, где только можно и нельзя, то это, ИМХО, контрпродуктивный подход. Никак не пойму, почему все так боятся SQL.
Наконец-то у рынка приходит понимание. Ну или хотя бы у отдельных личностей. К сожалению, пока что ситуация все равно печальная, потому что «монолит» превратился в ругательство. А использование микросервисов превратилось в религию. И как и каждая религия оно опирается исключительно на слепую веру во что-то. И на работе не редко приходится отстаивать позицию, что нам не нужны микросервисы. Но, как и с любой религией, логические аргументы просто бесполезны. Они пропускаются мимо, так же, как аргументы за теорию эволюцию пропускаются теми, кто верит в креационизм. Но тема религии в IT это уже отдельная тема для обсуждения. Она выходит далеко за пределы монолит vs микросервисы = )
У меня так бабуля недавно объявилась.
А почему имеет смысл делать это на бэке? Я про аналитические функции. Давайте возьмем простейшее. Нужно посчитать SUM() по разным срезам и, возможно, фильтрам. Допустим где-то по месяцам разбить, а где-то по годам. Причем само отношение, которое мы будем группировать, получается путем джойна 5 таблиц. Итак, что вы будете делать в БД, а что на бэке? Мой вариант — создать вьшку, которая джойнит эти 5 таблиц, а потом обращаться к ней с разными WHERE и GROUP BY, применяя SUM(), как агрегирующую функцию. Это будет в 5 раз короче, чем то же делать на бэке. Это будет быстрее. Это будет дешевле по памяти. Это будет удобнее поддерживать. В частности это удобнее читать. А какой Ваш вариант?
Речь не только про хранимки. Например нам нужно получить некоторое аналитическое представление каких-то данных в БД. Часто вижу, что это начинает лопатиться на бэке. С аргументацией "логики в БД быть не должно". Ну начнем с того, что даже фильтр по какому-то полю относится к логике. WHERE тоже на бэке будете делать? При тщательном рассмотрении можно понять, что БД — это и есть отражение предметной области с которой вы работаете. А если это не так, то Вас ждут проблемы. Где та грань, что нельзя делать в БД? Прям реально любопытно. Сможете рассказать?
В подавляющем большинстве случаев SQL сильно лучше для обработки данных, чем Python. Так что я прекрасно могу понять желание перенести все эти расчеты в БД. А если разработчик выучил Python и теперь пытается использовать его везде, где только можно и нельзя, то это, ИМХО, контрпродуктивный подход. Никак не пойму, почему все так боятся SQL.
Надеюсь во втором пункте была речь про временное снятие ограничений и их возврат после крупной вставки? Или все же речь про полный отказ от FK?
Я вот кинестетик. И ничего, работаю как-то программистом. Лихо вы как-то всех в визуалы записали = )