Какое количество строк в таблицах реляционных СУБД можно считать оптимальным?
Anonymous Quiz
6%
До 10к
12%
До 100к
34%
До 1М
31%
До 10М
17%
До 100М
🤔18👍5🤯3😭3
Какое оптимальное количество строк в таблицах реляционных СУБД?
На своем опыте использования разных СУБД и пообщавшись с более профильными ребятами DBE (Database Engineer) - я пришел к выводу, на сколько хорошо или плохо работают реляционные СУБД в зависимости от объема данных в таблицах:
1️⃣ От 0 до 10M - такое количество строк, пожалуй, является идеальным. Все SQL запросы по любым колонкам работают очень быстро, и даже full scan выполняется за доли секунды.
2️⃣ От 10М до 50М - это довольно увесистые таблицы, уже нужно задумываться о создании индексов и как написать хорошо SQL запросы. Нужно избегать full scan, если это возможно. Старые SQL запросы скорее всего придется пересмотреть и оптимизировать, потому что появляются проблемы с производительностью приложений.
3️⃣ От 50М до 100М - пора доставать задачи из бэклога о редизайне схемы базы данных, рассматривать партиционирование/шардирование (на уровне СУБД, если она это поддерживает, либо на уровне приложения). Или даже использование/переезд на другую СУБД, потому что релиз практически любой фичи сопряжен с какими-то проблемами. А старый функицонал все чаще выстреливает в ногу там, где даже не ожидал. Даже простейшее добавление/удаление колонки, создание нового индекса может привести к full outage.
4️⃣ От 100М до 1ММ - это как тонущий корабль, ибо поздно задумываться о чем-то - проблемы уже есть здесь и сейчас. А использовать какое-либо решение из пункта 3 сопряжено с большими проблемами или даже не является возможным.
Уже не помню из какой книги, но я достал для себя интересную мысль, которую применяю при написании алгоритмов или тех же SQL запросов:
Другими словами говоря, я ставлю себя на место машины/компьютера.
Например:
1️⃣ Переносить дрова по одной штуке сложнее, чем взять тележку (= использование батчей)
2️⃣ Если попросить друга, то выкопать картошку в огороде будет почти в 2 раза быстрее (= использование несколько ядер/потоков)
3️⃣ Поднимать вес гантель становится все сложнее с увеличением веса (= увеличению кол-ва строк в таблицах)
4️⃣ Искать номер телефона в справочнике гораздо быстрее, если он отсортирован по алфавиту (= использование сортировок и двоичного поиска)
PS. На фото - это я себе сделал подарок на НГ, чтобы выполнять силовые не выходя из дома 😁
На своем опыте использования разных СУБД и пообщавшись с более профильными ребятами DBE (Database Engineer) - я пришел к выводу, на сколько хорошо или плохо работают реляционные СУБД в зависимости от объема данных в таблицах:
1️⃣ От 0 до 10M - такое количество строк, пожалуй, является идеальным. Все SQL запросы по любым колонкам работают очень быстро, и даже full scan выполняется за доли секунды.
2️⃣ От 10М до 50М - это довольно увесистые таблицы, уже нужно задумываться о создании индексов и как написать хорошо SQL запросы. Нужно избегать full scan, если это возможно. Старые SQL запросы скорее всего придется пересмотреть и оптимизировать, потому что появляются проблемы с производительностью приложений.
3️⃣ От 50М до 100М - пора доставать задачи из бэклога о редизайне схемы базы данных, рассматривать партиционирование/шардирование (на уровне СУБД, если она это поддерживает, либо на уровне приложения). Или даже использование/переезд на другую СУБД, потому что релиз практически любой фичи сопряжен с какими-то проблемами. А старый функицонал все чаще выстреливает в ногу там, где даже не ожидал. Даже простейшее добавление/удаление колонки, создание нового индекса может привести к full outage.
4️⃣ От 100М до 1ММ - это как тонущий корабль, ибо поздно задумываться о чем-то - проблемы уже есть здесь и сейчас. А использовать какое-либо решение из пункта 3 сопряжено с большими проблемами или даже не является возможным.
Также нужно помнить не только о количестве, но и об объеме информации (количестве байт), которое занимает в среднем одна строка в таблице. Ибо если решить хранить там бинарники (картинки, файлы) или большие строки, то описанные выше проблемы как будто сдигаются и могут начаться гораздо раньше!
Уже не помню из какой книги, но я достал для себя интересную мысль, которую применяю при написании алгоритмов или тех же SQL запросов:
Eсли что-то сложно или дольше делать тебе, то и машине это будет сложнее/дольше.
Другими словами говоря, я ставлю себя на место машины/компьютера.
Например:
1️⃣ Переносить дрова по одной штуке сложнее, чем взять тележку (= использование батчей)
2️⃣ Если попросить друга, то выкопать картошку в огороде будет почти в 2 раза быстрее (= использование несколько ядер/потоков)
3️⃣ Поднимать вес гантель становится все сложнее с увеличением веса (= увеличению кол-ва строк в таблицах)
4️⃣ Искать номер телефона в справочнике гораздо быстрее, если он отсортирован по алфавиту (= использование сортировок и двоичного поиска)
PS. На фото - это я себе сделал подарок на НГ, чтобы выполнять силовые не выходя из дома 😁
👍46🔥15❤7❤🔥3
С Наступающим Новым 2025 Годом!
Каждый раз в конце декабря я подвожу итоги для себя лично, чего я досиг и какая работа была проделана мной. Все-таки, очень часто со временем забываются и даже обесцениваются свои же труды, хотя когда-то это же самое казалось стоящим!
1️⃣ Купил машину. Это было очень важное приобретение по сравнению со всеми остальными моими покупками машин, потому что в этот раз я ее приобрел больше для сына и семьи, нежели сугубо для себя одного. Но почему-то в этот раз у меня даже не было радости или какого-то восторга от приобритения. Было чувство, как будто я просто в магазин сходил. Не нравится, когда со временем тебя перестают радовать даже такие вещи.
2️⃣ Месяц жили с семьей на Кипре. Пожалуй, это было лучшее время для меня в этом году, когда все вместе, не нужно пропадать днями на работе, а погода позволяет выходить на пробежки в шортах и майке в декабре месяце. Здесь я получил очень много нового для себя опыта, начиная от левостороннего движения и заканчивая первым в жизни землетрясением. Именно такой опыт увеличивает плостность твоей жизни, от чего кажется, что она становится еще длиннее и насыщеннее!
3️⃣ Взял 3 разряд в беге и триатлоне. Спорт - это не только про преодоление себя, дисциплину и прочее, хотя это одно из важнейших его качеств. Благодаря бегу я начал много читать книг (только ~7 за этот год) и интересоваться физиологией человека, как устроены наши тела, как происходит энергопотребление и другие очень важные процессы внутри нас (даже курс по долголетию прошел!). Тем самым я стал еще больше и усиленнее следить за тем, что я кушаю, пью, сплю, какие физ упражнения делаю, работаю и т.д. С возрастом здоровье только набирает ценность и становится все важнее и важнее для тебя.
4️⃣ Погасил ипотеку за квартиру. Покупка очередной квартиры, как и покупка очередной машины - больше не приносит того же восторга и удовольствия. Но отсутствие всяких кредитов явно делает мою жизнь спокойнее и менее стрессовой. А это дорогого стоит в наше время! Так что как и раньше - буду всеми силами в будущем отказываться от взятия всяких кредитов/ипотек и т.д.
5️⃣ Провел 4 группы менторства DMdev. В отличие от своей основной работы в Google, здесь я получаю настоящую благодарность от людей за то, что помог им реализовать их планы и цели в жизни. Это очень сильно помогает мне в получении душевного спокойствия. Поэтому буду стараться проводить их и дальше, пока это возможно!
6️⃣ Закончил курс по Docker. Это был единственный курс в этом году, хотя планировал изначально два. Законченные дела - это то, что помогает быть более дисциплинированным, ведь начинать что-то делать гораздо проще, чем продолжать и заканчивать. Для этого приходится брать силу воли и идти дальше, когда совсем уж и не хочется.
Теперь, написав все на бумаге, мне становится приятнее осознавать (или даже "осязать"), что не зря прошел этот год и можно заслуженно позволить себе отдохнуть на Новый Год, чтобы потом сразу же поставить перед собой новые цели. Ведь без целей твой фокус внимания будет метаться из стороны в сторону, и все силы (как и твое время) будут уходить вникуда.
❄️ ❄️ ❄️ ❄️ ❄️ ❄️
Поэтому всем желаю похвалить себя за пройденный путь и проделанный труд в 2024 году, загадать и идти к своим самым амбициозным желаниям в 2025 году, не спешить жить и замедляться, проводить больше времени с семьей и близкими, и просто человеческого счастья! Ваш Денис 🥳
Каждый раз в конце декабря я подвожу итоги для себя лично, чего я досиг и какая работа была проделана мной. Все-таки, очень часто со временем забываются и даже обесцениваются свои же труды, хотя когда-то это же самое казалось стоящим!
1️⃣ Купил машину. Это было очень важное приобретение по сравнению со всеми остальными моими покупками машин, потому что в этот раз я ее приобрел больше для сына и семьи, нежели сугубо для себя одного. Но почему-то в этот раз у меня даже не было радости или какого-то восторга от приобритения. Было чувство, как будто я просто в магазин сходил. Не нравится, когда со временем тебя перестают радовать даже такие вещи.
2️⃣ Месяц жили с семьей на Кипре. Пожалуй, это было лучшее время для меня в этом году, когда все вместе, не нужно пропадать днями на работе, а погода позволяет выходить на пробежки в шортах и майке в декабре месяце. Здесь я получил очень много нового для себя опыта, начиная от левостороннего движения и заканчивая первым в жизни землетрясением. Именно такой опыт увеличивает плостность твоей жизни, от чего кажется, что она становится еще длиннее и насыщеннее!
3️⃣ Взял 3 разряд в беге и триатлоне. Спорт - это не только про преодоление себя, дисциплину и прочее, хотя это одно из важнейших его качеств. Благодаря бегу я начал много читать книг (только ~7 за этот год) и интересоваться физиологией человека, как устроены наши тела, как происходит энергопотребление и другие очень важные процессы внутри нас (даже курс по долголетию прошел!). Тем самым я стал еще больше и усиленнее следить за тем, что я кушаю, пью, сплю, какие физ упражнения делаю, работаю и т.д. С возрастом здоровье только набирает ценность и становится все важнее и важнее для тебя.
4️⃣ Погасил ипотеку за квартиру. Покупка очередной квартиры, как и покупка очередной машины - больше не приносит того же восторга и удовольствия. Но отсутствие всяких кредитов явно делает мою жизнь спокойнее и менее стрессовой. А это дорогого стоит в наше время! Так что как и раньше - буду всеми силами в будущем отказываться от взятия всяких кредитов/ипотек и т.д.
5️⃣ Провел 4 группы менторства DMdev. В отличие от своей основной работы в Google, здесь я получаю настоящую благодарность от людей за то, что помог им реализовать их планы и цели в жизни. Это очень сильно помогает мне в получении душевного спокойствия. Поэтому буду стараться проводить их и дальше, пока это возможно!
6️⃣ Закончил курс по Docker. Это был единственный курс в этом году, хотя планировал изначально два. Законченные дела - это то, что помогает быть более дисциплинированным, ведь начинать что-то делать гораздо проще, чем продолжать и заканчивать. Для этого приходится брать силу воли и идти дальше, когда совсем уж и не хочется.
Теперь, написав все на бумаге, мне становится приятнее осознавать (или даже "осязать"), что не зря прошел этот год и можно заслуженно позволить себе отдохнуть на Новый Год, чтобы потом сразу же поставить перед собой новые цели. Ведь без целей твой фокус внимания будет метаться из стороны в сторону, и все силы (как и твое время) будут уходить вникуда.
Поэтому всем желаю похвалить себя за пройденный путь и проделанный труд в 2024 году, загадать и идти к своим самым амбициозным желаниям в 2025 году, не спешить жить и замедляться, проводить больше времени с семьей и близкими, и просто человеческого счастья! Ваш Денис 🥳
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥110❤33👍19🎉8🤩2🏆1🍾1
У меня новый год начался на работе с задач по аналитике. С ней мне не приходилось работать с тех пор, как я устроился в Google.
И что я понял... Что прогресс не стоит на месте даже здесь. Если раньше я использовал BigQuery для построения запросов и Looker для визуализации аналитических данных, то сейчас я вообще никак не ограничен в способах получения данных.
Я могу использовать в одном запросе данные из BigQuery, Spanner, да даже csv файл могу заджойнить! О такой гибкости я мог только мечтать.
Поэтому смело инвестируй свое время в SQL. Это, пожалуй, такой же ключевой навык для backend разработчика, как и знание Bash. Причем оба инструмента старше меня. Как говорится, великое актуально всегда :)
И что я понял... Что прогресс не стоит на месте даже здесь. Если раньше я использовал BigQuery для построения запросов и Looker для визуализации аналитических данных, то сейчас я вообще никак не ограничен в способах получения данных.
Я могу использовать в одном запросе данные из BigQuery, Spanner, да даже csv файл могу заджойнить! О такой гибкости я мог только мечтать.
Но самое главное, что для всего этого мне достаточно хорошо знать SQL, потому что этот язык с небольшими диалектами/изменениями используется везде! А он, на минуточку, был создан в далеком 1974 году, т.е. уже 50 лет назад.
Поэтому смело инвестируй свое время в SQL. Это, пожалуй, такой же ключевой навык для backend разработчика, как и знание Bash. Причем оба инструмента старше меня. Как говорится, великое актуально всегда :)
❤🔥26👍23🔥11❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Top Alerts
Я уже не раз в своих постах затрагивал тему логов и метрик, чтобы донести на сколько важны они в системе. И возвращаясь к метрикам: какой топ самых распространенных алертов, которые должны быть настроены у каждого?
1️⃣ Availability - доступность сервиса. Или иначе: как много 5xx ошибок возвращается клиентам по сравнению с другими статусами.
2️⃣ Latency - как много времени сервису трубется для обработки одного запроса. Если оно становится больше, то это может свидетельствовать о каких-то внутренних неполадках (например, downstream сервис или база данных подтормаживают, SQL запросы не оптимизированы, и т.д.). Также это каскадно может привести к проблемам у upstream сервисов.
3️⃣ Traffic absence - отсутствие траффика вообще, когда ни одного запроса не достигает твоего сервиса на протяжении часа, двух, суток и т.д. Это свидетельствует о проблемах на уровень выше, в инфрастуктуре или на стороне клиента. Часто про этот алерт забывают, но он невероятно важен как и два предыдущих!
В любом случае, алерты - это конечно хорошо, но очень уж не нравится просыпаться среди ночи, когда они звонят тебе на телефон 🥲
Я уже не раз в своих постах затрагивал тему логов и метрик, чтобы донести на сколько важны они в системе. И возвращаясь к метрикам: какой топ самых распространенных алертов, которые должны быть настроены у каждого?
1️⃣ Availability - доступность сервиса. Или иначе: как много 5xx ошибок возвращается клиентам по сравнению с другими статусами.
2️⃣ Latency - как много времени сервису трубется для обработки одного запроса. Если оно становится больше, то это может свидетельствовать о каких-то внутренних неполадках (например, downstream сервис или база данных подтормаживают, SQL запросы не оптимизированы, и т.д.). Также это каскадно может привести к проблемам у upstream сервисов.
3️⃣ Traffic absence - отсутствие траффика вообще, когда ни одного запроса не достигает твоего сервиса на протяжении часа, двух, суток и т.д. Это свидетельствует о проблемах на уровень выше, в инфрастуктуре или на стороне клиента. Часто про этот алерт забывают, но он невероятно важен как и два предыдущих!
В любом случае, алерты - это конечно хорошо, но очень уж не нравится просыпаться среди ночи, когда они звонят тебе на телефон 🥲
👍34🔥9❤🔥2❤1
Фото для привлечения внимания 😁
Осталось 3 места на менторство DMdev 1 ступени
Записывайся, будем прокачивать мозги, а не тело💻
Да начнется трансформация!
👇
клик-клик
Осталось 3 места на менторство DMdev 1 ступени
Записывайся, будем прокачивать мозги, а не тело
Да начнется трансформация!
👇
клик-клик
Please open Telegram to view this post
VIEW IN TELEGRAM
😁67🔥15👍5⚡1👏1🤔1🌚1
Учитель - это не тот, кто скажет тебе нечто, о чем другие до него не могли сказать. Учитель станет твоим другом, потому что скажет так, что ты наконец-то услышишь
Что-то в этом есть. Сам помню, как бывает слушаешь ту же самую сложную тему, которую плохо понимаешь, но от другого человека - и мир как будто начинает играть новыми красками, и до тебя наконец-то доходит.
Также очень сильно влияет то, КАК до тебя доносят информацию, используя уже известные тебе знания, термины, понятия и т.д. По-другому говоря, объясняют "неизвестное" через "известное".
Если же говорить про Java, то очень важно постепенно изучать ее по моему Roadmap, не пропуская какие-то темы. Даже если тебе, как ученику, кажется, что это не нужно и можно пропустить парочку курсов!
PS. Календарь настоящий, у меня дома на кухонном столе стоит 🙂
Что-то в этом есть. Сам помню, как бывает слушаешь ту же самую сложную тему, которую плохо понимаешь, но от другого человека - и мир как будто начинает играть новыми красками, и до тебя наконец-то доходит.
Также очень сильно влияет то, КАК до тебя доносят информацию, используя уже известные тебе знания, термины, понятия и т.д. По-другому говоря, объясняют "неизвестное" через "известное".
Если же говорить про Java, то очень важно постепенно изучать ее по моему Roadmap, не пропуская какие-то темы. Даже если тебе, как ученику, кажется, что это не нужно и можно пропустить парочку курсов!
PS. Календарь настоящий, у меня дома на кухонном столе стоит 🙂
👍43🔥14❤4🤔3
На Java сейчас в основном проекты на поддержке, а новые в сфере применения Java пишутся на Go или JS. Так ли это?
Начну с того, что когда я учился в университете БГУИР в далеком 2009 году, я всегда думал, что все вокруг меня пишут на C/C++. А значит и мне надо учить этот язык, чтобы устроиться на работу.
Потом я работал в компании Godel Technologies, где большинство проектов были написаны на C#, причем количество проектов этих только увеличивалось со временем, а проектов по Java уменьшалось здесь. И закрадывалась мысль, что вот-вот и C# поборет Java и нужно свичнуться на него побыстрее.
К чему это я?
Если хочется более объективной оценки, то лучше смотреть на вакансии в интересующем тебя регионе или на мировые рейтинги языков программирования, например, TIOBE или GitHub.
Лично я предпочитаю TIOBE, потому что он основан на анализе поисковых запросов по языку программирования, активности сообщества разработчиков, количестве вакансий и проектов. Он обновляется ежемесячно.
GitHub же не совсем объективен по моему мнению, потому что большинство компаний (тем более таких больших как MAANG) не держат там свой код. И, наоборот, студенты и фрилансеры активно его используют.
Также нужно обращать внимание на доменную область применения языка. Например, Python находится на первом месте в рейтингах потому, что сейчас нейронные сети и AI на хайпе. Но это не значит, что прикладные программы, enterprise, мобильные приложения и веб пишутся на нем с той же популярностью - это совсем не так. Эти области заняты другими языками.
Python - это обычно про data science и machine learning (и то он переписывается на C++, если нужно установить приложение на пользовательские устройства).
Что же касается изначального вопроса про Go - то, работая в компании Google, которая создала его, могу сказать, что он занял здесь лишь свою небольшую нишу. Так что до сих пор при выборе языка программирования для backend разработки новых сервисов - здесь предпочтительным является Java/Kotlin.
Теперь, напоследок, хочу добавить следующее:
Начну с того, что когда я учился в университете БГУИР в далеком 2009 году, я всегда думал, что все вокруг меня пишут на C/C++. А значит и мне надо учить этот язык, чтобы устроиться на работу.
Потом я работал в компании Godel Technologies, где большинство проектов были написаны на C#, причем количество проектов этих только увеличивалось со временем, а проектов по Java уменьшалось здесь. И закрадывалась мысль, что вот-вот и C# поборет Java и нужно свичнуться на него побыстрее.
К чему это я?
А к тому, что нужно шире смотреть на вещи, а не на обстановку и людей вокруг тебя, потому что таким образом сильно сужается точка зрения. Но самое главное, что зачастую она не объективна и даже не верна (и это относится не только к программированию, а вообще ко всему).
Если хочется более объективной оценки, то лучше смотреть на вакансии в интересующем тебя регионе или на мировые рейтинги языков программирования, например, TIOBE или GitHub.
Лично я предпочитаю TIOBE, потому что он основан на анализе поисковых запросов по языку программирования, активности сообщества разработчиков, количестве вакансий и проектов. Он обновляется ежемесячно.
GitHub же не совсем объективен по моему мнению, потому что большинство компаний (тем более таких больших как MAANG) не держат там свой код. И, наоборот, студенты и фрилансеры активно его используют.
Также нужно обращать внимание на доменную область применения языка. Например, Python находится на первом месте в рейтингах потому, что сейчас нейронные сети и AI на хайпе. Но это не значит, что прикладные программы, enterprise, мобильные приложения и веб пишутся на нем с той же популярностью - это совсем не так. Эти области заняты другими языками.
Python - это обычно про data science и machine learning (и то он переписывается на C++, если нужно установить приложение на пользовательские устройства).
Что же касается изначального вопроса про Go - то, работая в компании Google, которая создала его, могу сказать, что он занял здесь лишь свою небольшую нишу. Так что до сих пор при выборе языка программирования для backend разработки новых сервисов - здесь предпочтительным является Java/Kotlin.
Теперь, напоследок, хочу добавить следующее:
Один язык не является фундаментально лучше или хуже другого. Выбор языка зачастую основывается на опыте инженеров, кто будет писать приложение, проблемной области, которую нужно решить, и уже построенной экосистемы внутри компании.
👍72🔥14❤🔥5
Ровно неделя до старта менторства DMdev!
Еще осталось:
- 2 места на 1 ступень (записаться)
- освободилось 1 место ко мне на 2 ступень! (записаться)
Если все еще сомневаешься идти или нет, то просто напиши по любым вопросам @karina_matveyenka
PS. Примеры финальных проектов, которые у вас будут по окончании менторства, можно посмотреть на YouTube:
- 1 ступень
- 2 ступень
Еще осталось:
- 2 места на 1 ступень (записаться)
- освободилось 1 место ко мне на 2 ступень! (записаться)
Если все еще сомневаешься идти или нет, то просто напиши по любым вопросам @karina_matveyenka
PS. Примеры финальных проектов, которые у вас будут по окончании менторства, можно посмотреть на YouTube:
- 1 ступень
- 2 ступень
🔥11👍7❤🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Самый младший студент на первой ступени менторства😁
Юбилейный 15ый старт двух ступеней состоялся 🎉
Впереди 3,5 месяца насыщенной и продуктивной работы!
Цель поставили, план наметили - осталось только действовать.
Спасибо каждому за доверие, let’s go 🚀
P.S. Для тех, кто любит прыгнуть в последний вагон -> еще два человека могут присоединиться
(писать @karina_matveyenka)
Юбилейный 15ый старт двух ступеней состоялся 🎉
Впереди 3,5 месяца насыщенной и продуктивной работы!
Цель поставили, план наметили - осталось только действовать.
Спасибо каждому за доверие, let’s go 🚀
P.S. Для тех, кто любит прыгнуть в последний вагон -> еще два человека могут присоединиться
(писать @karina_matveyenka)
🎉38🔥20😁9❤🔥4❤3⚡1👍1
Хочу завести новую рубрику: ответы на ваши анонимные вопросы 💻
Часто вопросы задаются в коментариях к постам, под разными видео.
Они теряются и порой остаются неотвеченными.
Теперь для ваших вопросов есть отдельное место, буду отвечать по возможности тут в телеграм канале или инстаграм https://www.instagram.com/denis.dmdev
P.S. Я не буду видеть, кто задал вопрос, они будут полностью анонимны.
Задать вопрос:
👇
https://forms.gle/FLHEHQ7GcSNjmtku5
Часто вопросы задаются в коментариях к постам, под разными видео.
Они теряются и порой остаются неотвеченными.
Теперь для ваших вопросов есть отдельное место, буду отвечать по возможности тут в телеграм канале или инстаграм https://www.instagram.com/denis.dmdev
P.S. Я не буду видеть, кто задал вопрос, они будут полностью анонимны.
Задать вопрос:
👇
https://forms.gle/FLHEHQ7GcSNjmtku5
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Docs
Твой вопрос к DMdev
Здесь можно задать любой анонимный вопрос
Ответ можно будет увидеть в telegram канале https://t.me/dmdev_talks или instagram https://www.instagram.com/denis.dmdev
Ответ можно будет увидеть в telegram канале https://t.me/dmdev_talks или instagram https://www.instagram.com/denis.dmdev
👍41❤🔥6🤔2❤1
Отвечаю на #ВашВопрос
👇
В каком layer-е нужно маппить DTO? В сервисе или контроллере?
Обычно все происходит на уровне сервисов, где есть доступ к сущностям и еще открыта транзакция. Это позволяет предоставить в dto все необходимые данные, что часто требует выполнения новых запросов в СУБД.
На уровне контроллеров уже не должно быть транзакции, а значит:
- либо не получится так гибко сконструировать dto
- либо упадет какое-нибудь исключение (знаменитое LazyInitializationException)
- либо придется вызывать другие методы сервисов.
Также в большинстве случаев достаточно лишь одной dto на чтение одной сущности, чтобы в последующем передать ее клиенту по http или другому протоколу. Если же необходимы разные представления, то просто mapper/converter можно передать в качестве дополнительно параметра в метод сервиса, например:
А для тех, кто любит открывать транзакции выше уровня сервисов и ничего не видит плохого оставлять property spring.jpa.open-in-view: true - есть неплохая статья для прочтения.
👇
В каком layer-е нужно маппить DTO? В сервисе или контроллере?
Обычно все происходит на уровне сервисов, где есть доступ к сущностям и еще открыта транзакция. Это позволяет предоставить в dto все необходимые данные, что часто требует выполнения новых запросов в СУБД.
На уровне контроллеров уже не должно быть транзакции, а значит:
- либо не получится так гибко сконструировать dto
- либо упадет какое-нибудь исключение (знаменитое LazyInitializationException)
- либо придется вызывать другие методы сервисов.
Также в большинстве случаев достаточно лишь одной dto на чтение одной сущности, чтобы в последующем передать ее клиенту по http или другому протоколу. Если же необходимы разные представления, то просто mapper/converter можно передать в качестве дополнительно параметра в метод сервиса, например:
// Это использование дефолтного маппера
public Optional<UserReadDto> findById(Long id) {
return userRepository.findById(id)
.map(userReadMapper::map);
}
// Это использование динамического маппера, переданного с контроллера
public Optional<T> findById(Long id, Mapper<User, T> mapper) {
return userRepository.findById(id)
.map(mapper::map);
}
А для тех, кто любит открывать транзакции выше уровня сервисов и ничего не видит плохого оставлять property spring.jpa.open-in-view: true - есть неплохая статья для прочтения.
👍48❤🔥7🔥6❤2
Когда ты только начинаешь заниматься программированием, то что бы ты ни делал - это будет улучшать твои навыки. Даже смежные темы, например, решение примеров по алгебре или геометрии за 8 класс - улучшат твое мышление в программировании. Поэтому, конечно же, такой быстрый прогресс очень сильно может замотивировать: сравнительно мало усилий прилагается для сравнительно большого результата.
Но с течением времени таких зон для улучшений становится все меньше и меньше. И, наоборот, сил и времени приходится тратить все больше и больше, чтобы спрогрессировать хотя бы на чуть-чуть. Более того, ты не всегда даже понимаешь, что может помочь тебе в этом (или просто уже не хочешь). Это ведет к тому, что на каком-то этапе, у всех по разному, человек может остановиться и не развиваться дальше. У кого-то это на уровне Junior, у кого-то Middle, у кого-то Senior.
Следующий интересный факт: навыки притупляются без использования. А значит для поддержания какого-то определенного уровня нужно постоянно выполнять какой-то минимум работ. Например, если у тебя когда-то алгоритмы отлетали назубок, то через пару лет без практики тебе придется неплохо так попотеть, чтобы просто повернуть односвязный список. И, наоборот, решая по 1-2 задачке в неделю будет достаточно, чтобы на протяжении долго времени держать этот навык в тонусе.
Но есть и хорошая новость: достигнув какого-то уровня, например, Lead, очень легко и с гораздо меньшими затраченными усилиями потребуется, чтобы вновь оказаться там после долгого перерыва.
Но с течением времени таких зон для улучшений становится все меньше и меньше. И, наоборот, сил и времени приходится тратить все больше и больше, чтобы спрогрессировать хотя бы на чуть-чуть. Более того, ты не всегда даже понимаешь, что может помочь тебе в этом (или просто уже не хочешь). Это ведет к тому, что на каком-то этапе, у всех по разному, человек может остановиться и не развиваться дальше. У кого-то это на уровне Junior, у кого-то Middle, у кого-то Senior.
Следующий интересный факт: навыки притупляются без использования. А значит для поддержания какого-то определенного уровня нужно постоянно выполнять какой-то минимум работ. Например, если у тебя когда-то алгоритмы отлетали назубок, то через пару лет без практики тебе придется неплохо так попотеть, чтобы просто повернуть односвязный список. И, наоборот, решая по 1-2 задачке в неделю будет достаточно, чтобы на протяжении долго времени держать этот навык в тонусе.
Но есть и хорошая новость: достигнув какого-то уровня, например, Lead, очень легко и с гораздо меньшими затраченными усилиями потребуется, чтобы вновь оказаться там после долгого перерыва.
🔥34👍14❤4❤🔥4💯3
☝️Лазейка, как купить пакет из всех моих курсов со скидкой 67% и получить в подарок участие в первом закрытом вебинаре «Микросервисы» 🎁
Сейчас:14.999 rub на полгода
18 марта: 4.999 rub на год
ПРАЗДНИЧНАЯ РАСПРОДАЖА
Сейчас:
18 марта: 4.999 rub на год
ПРАЗДНИЧНАЯ РАСПРОДАЖА
🔥67👍13❤3🤩3💩2🏆2
#ВашВопрос
👇
Где лучше выбрасывать исключения? На уровне сервисов там где и основная бизнес логика или на уровне контроллеров?
Исключения должны выбрасываться в тех местах, где продолжение программы невозможно, потому что состояние выполнения запроса не верно ввиду каких-то логических условий. Вопрос здесь в другом - где лучше обрабатывать исключения. А вот здесь уже большое поле для выбора.
1. Начнем с самого простого: ошибки базы данных нет смысла обрабатывать на уровне dao/repository, потому что в таком случае клиент даже не узнает, произошло успешное выполнение запроса и состояние сохранилось в базе или нет.
2. Пункт 1 ведет к тому, что ошибки обрабатываются на уровнях выше: service, controller, http filters, kafka consumers, etc. Поэтому вопрос становится следующий:
Если ответ да - обрабатываем и продолжаем выполнять код программы. В противном случае пробрасываем ошибку выше и прерываем выполнение.
3. Если на пункте 2 мы и так находимся на последнем уровене, то нам придется принять решение о том, как обработать ошибку и какой вернуть ответ клиенту/пользователю.
👇
Где лучше выбрасывать исключения? На уровне сервисов там где и основная бизнес логика или на уровне контроллеров?
Исключения должны выбрасываться в тех местах, где продолжение программы невозможно, потому что состояние выполнения запроса не верно ввиду каких-то логических условий. Вопрос здесь в другом - где лучше обрабатывать исключения. А вот здесь уже большое поле для выбора.
1. Начнем с самого простого: ошибки базы данных нет смысла обрабатывать на уровне dao/repository, потому что в таком случае клиент даже не узнает, произошло успешное выполнение запроса и состояние сохранилось в базе или нет.
2. Пункт 1 ведет к тому, что ошибки обрабатываются на уровнях выше: service, controller, http filters, kafka consumers, etc. Поэтому вопрос становится следующий:
можем ли мы обработать ошибку здесь и сейчас, чтобы продолжить ход выполнения программы, или же нам нужно пробросить на уровень выше, потому что на текущем уровне мы не можем принять этого решения?
Если ответ да - обрабатываем и продолжаем выполнять код программы. В противном случае пробрасываем ошибку выше и прерываем выполнение.
3. Если на пункте 2 мы и так находимся на последнем уровене, то нам придется принять решение о том, как обработать ошибку и какой вернуть ответ клиенту/пользователю.
👍36🔥7❤6