Интересная статья, конечно. А как часто рекрутер знает про процессы компании, с которыми столкнется ИТ специалист, или обстановку в коллективе определенного проекта. Как там ставят задачи, хаос там или нет? А если компания большая и у этого специалиста много собеседований в день, а ещё есть другая работа? И где гарантия, что собеседующий обладает достаточными знаниями и логикой, чтобы сделать правильный вывод из ответа кандидата? Релевантность таких выводов под большим вопросом, на мой взгляд. Но может это просто плохой опыт...
1) видимо такую ситуацию и поймали, когда не влезло в work_mem. Но для этого запроса не актуально, он не увеличивает количество памяти по сравнению с версией без CTE.
Не очень согласен, что это логичнее для человека, особенно, который не сильно погружен и не думает, как планировщик запросов.
Подскажите, пожалуйста, по CTE. Пишется ли что-то на диск, при создании CTE? В старых версиях работало не очень быстро в условиях большой нагрузки, много похожих запросов с CTE нагружали дисковую подсистему и фактически выполнялись дольше, чем без CTE. И там в запросе с массивом не надо ли dts[0] вместо dts[1]? У нас же по идее в массив даты в обратном порядке должны собираться, так как сортировка desc?
Объяснять очень общие абстракции другими, не очень понятными абстракциями, не самый быстрый путь к пониманию...
Обычно нужны примеры кода, а ещё такие примеры кода, которые демонстрируют не абстракции сами по себе, а то, какой выигрыш они дают, по сравнению с кодом, который не использует эти абстракции...
Как я понимаю FK поддерживаются, иначе эта статья не имела бы смысла (если нельзя использовать, то и обсуждать нечего). Я не отрицаю, что бывают случаи, когда от FK отказываются. Но это как отказываться от автоматической коробки передач в машине. Отказаться можно, но придется самому переключать передачи, жать сцепление. И микросервисы и шардирование сами по себе не отменяют FK. Всё зависит от стратегии хранения данных, требований к обеспечению целостности данных, или от типа системы по CAP теореме. Могут быть и nosql решения. Но тут же статья про реляционные БД, и FK это один из инструментов, достаточно сильный и удобный для своих целей.
Жёстко, конечно. Видно, что не так много опыта. Кроме очевидных вещей, которые умные люди подсветили выше. Есть ещё и не очень очевидная - это изучение системы новым человеком. Если у вас будет больше 30 сущностей без внешних ключей, а ещё если наименования ключевых полей в родительских и дочерних таблицах отличаются, то большой вам удачи в изучении. Можно, конечно, модель в коде посмотреть, но это уже будет строк 600-700. А по внешним ключам многие редакторы БД могут строить схемы, которые уже можно изучать и понимать. До 50 сущностей можно кататься на велосипеде как угодно. В моей практике было 1800 сущностей в большой системе. Пофантазируйте, как это выжило бы в вашей парадигме. Самую горькую усмешку вызвала фраза "в нормально спроектированном бэкенде"...
Postgresql Просто для своей работы требует много ресурсов. Там же постоянно идут процессы сохранений на диск кеша базы в оперативной памяти. Вакуумы, аналайзы, другие внутренние процессы с перестроением индексов. Чтобы сравнение было честным. Нужно поднимать отдельную СУБД только с unlogged таблицами. И основную на другом сервере. Думаю, что при определенных условиях БД себя покажет лучше чем в этом тесте. Наверное, тут если не хватает производительности - нужно использовать redis, она сильно проще масштабируется. С кеш есть другие проблемы, связанные с целостностью данных, которые придётся решать дополнительно.
Интересная статья, конечно. А как часто рекрутер знает про процессы компании, с которыми столкнется ИТ специалист, или обстановку в коллективе определенного проекта. Как там ставят задачи, хаос там или нет? А если компания большая и у этого специалиста много собеседований в день, а ещё есть другая работа? И где гарантия, что собеседующий обладает достаточными знаниями и логикой, чтобы сделать правильный вывод из ответа кандидата? Релевантность таких выводов под большим вопросом, на мой взгляд. Но может это просто плохой опыт...
Очень научно о том, что llm не всегда даёт правильный ответ. Особенно в сложных сценариях.
1) видимо такую ситуацию и поймали, когда не влезло в work_mem. Но для этого запроса не актуально, он не увеличивает количество памяти по сравнению с версией без CTE.
2) Забыл об этом.
Спасибо.
Спасибо
Хорошая оптимизация запроса.
Не очень согласен, что это логичнее для человека, особенно, который не сильно погружен и не думает, как планировщик запросов.
Подскажите, пожалуйста, по CTE. Пишется ли что-то на диск, при создании CTE? В старых версиях работало не очень быстро в условиях большой нагрузки, много похожих запросов с CTE нагружали дисковую подсистему и фактически выполнялись дольше, чем без CTE. И там в запросе с массивом не надо ли dts[0] вместо dts[1]? У нас же по идее в массив даты в обратном порядке должны собираться, так как сортировка desc?
Объяснять очень общие абстракции другими, не очень понятными абстракциями, не самый быстрый путь к пониманию...
Обычно нужны примеры кода, а ещё такие примеры кода, которые демонстрируют не абстракции сами по себе, а то, какой выигрыш они дают, по сравнению с кодом, который не использует эти абстракции...
Мне понравилась статья. Общий принцип отражает. Если глубже погружаться, будет скучнее:)
Как я понимаю FK поддерживаются, иначе эта статья не имела бы смысла (если нельзя использовать, то и обсуждать нечего). Я не отрицаю, что бывают случаи, когда от FK отказываются. Но это как отказываться от автоматической коробки передач в машине. Отказаться можно, но придется самому переключать передачи, жать сцепление. И микросервисы и шардирование сами по себе не отменяют FK. Всё зависит от стратегии хранения данных, требований к обеспечению целостности данных, или от типа системы по CAP теореме. Могут быть и nosql решения. Но тут же статья про реляционные БД, и FK это один из инструментов, достаточно сильный и удобный для своих целей.
Жёстко, конечно. Видно, что не так много опыта. Кроме очевидных вещей, которые умные люди подсветили выше. Есть ещё и не очень очевидная - это изучение системы новым человеком. Если у вас будет больше 30 сущностей без внешних ключей, а ещё если наименования ключевых полей в родительских и дочерних таблицах отличаются, то большой вам удачи в изучении. Можно, конечно, модель в коде посмотреть, но это уже будет строк 600-700. А по внешним ключам многие редакторы БД могут строить схемы, которые уже можно изучать и понимать. До 50 сущностей можно кататься на велосипеде как угодно. В моей практике было 1800 сущностей в большой системе. Пофантазируйте, как это выжило бы в вашей парадигме. Самую горькую усмешку вызвала фраза "в нормально спроектированном бэкенде"...
Postgresql Просто для своей работы требует много ресурсов. Там же постоянно идут процессы сохранений на диск кеша базы в оперативной памяти. Вакуумы, аналайзы, другие внутренние процессы с перестроением индексов. Чтобы сравнение было честным. Нужно поднимать отдельную СУБД только с unlogged таблицами. И основную на другом сервере. Думаю, что при определенных условиях БД себя покажет лучше чем в этом тесте. Наверное, тут если не хватает производительности - нужно использовать redis, она сильно проще масштабируется. С кеш есть другие проблемы, связанные с целостностью данных, которые придётся решать дополнительно.