Следовательно, один из тест-кейсов должен содержать проверки на соответствие метаданных этих таблиц ожидаемым значениям.
Разработчики не должны создавать таблицы вручную. А если они создаются кодом, как положено, и мигрируют на новую версию тоже кодом (то есть имеет место повторяемость), то трудоемкость написания того, что вы тут показываете, выглядит намного большей, чем трудоемкость написания DDL для самого создания таблиц. Ну т.е. тест должен по сложности примерно соответствовать сложности написания CREATE TABLE, иначе вы замучаетесь его сопровождать.
Ну т.е. сама по себе идея проверять соответствие схемы базы требованиям - она несомненно правильная, но показанное решение выглядит как не слишком гибкое и трудоемкое в разработке. Ну или возможно что я вас не очень понял, вы описали внутренности инструмента, а на самом деле реальные тесты выглядят совсем несложно и пишутся/сопровождаются легко и быстро?
Составить более детальные требования - это время (и деньги) тимлида. Указать разные веса - тоже самое. Если цель время и деньги тимлида экономить, заставлять его детализировать описание и расставлять веса - нонсенс.
Чем детальнее они составлены, тем точнее будет оценка.
Ну вот в моем случае вообще никогда не нужно 100 попадание в вакансию. Мы вполне готовы брать (и берем) людей, которые дополняют команду. При этом отсутствующие навыки либо дообучаются в работе, либо эту часть работы может сделать другой член команды. В состоянии ли HR (или же ИИ) этот фактор учесть - я не уверен, слишком много контекста ему для этого нужно дать.
Ну, я ваш коммент понял так, что типовой HR тоже не различает эти ключевые слова, раз указали LiquiBase - значит должно быть (а что flyway может быть заменой - не понимаем). И если вы об этом - то я скорее согласен.
Но если уж мы пытаемся белкового заменить на ИИ, то вот эти вот веса или важности ключевым словам не мешало бы попробовать добавить. А то получается матрица компетенций в чистом виде, которая на программистах практически не работает. Ну т.е. она может и работает - если мы имеем дело с типовыми винтиками, но как только что-то нестандартное - так все. И в первую очередь именно потому, что навыков в штуках - кучи, они все разной важности, они связаны друг с другом, и человек это все оценивает достаточно быстро и легко - разумеется речь про скажем тимлида, который и писал описание вакансии, и который понимает, что ну нету в резюме JUnit, зато есть TestNG - ну так и фиг с ним, это одно и тоже.
LiquiBase это мелкий фреймворк, предназначенный для решения конкретной задачи, не единственный в своей нише (flyway вспоминается на раз-два). Синьору с 10 годами опыта нужно на освоение может пару часов, чтобы начать работать.
SQL - это наоборот, тема необъятная. Во-первых, существует множество версий даже стандарта, которые все время выходят новые (последний вроде 2023, при этом я например стараюсь укладываться в рамки SQL-92). Во-вторых, существует множество даже широко используемых СУБД, которые отличаются в нюансах. И сильно отличаются. На то, чтобы "знать" SQL можно потратить годы, в тоже время скажем базовый курс по нему - это несколько занятий.
опыт работы с СУБД PostgreSQL - ну это примерно как знание SQL, только в более узком смысле. Я думаю тоже можно потратить годы, чтобы скажем стать квалифицированным DBA.
Итого, что в сухом остатке? Предлагается механизм оценки резюме, где три приведенные выше (просто для примера, точно такой же разбор можно провести по остальным пунктам) темы считаются равноценными, в то время как на самом деле они по сложности освоения различаются на порядки. В таком виде все это бессмысленная фигня. Не может оценка 10/10 по LiquiBase стоить столько же, как оценка 2/10 по SQL. Это все еще разница на порядки.
Согласен. Более того, как можно быть ненадежным и непредсказуемым лидером, так и одних надежности и предсказуемости недостаточно, чтобы им стать. То есть, это хорошие для лидера качества, но непосредственно и только благодаря им лидером не становятся.
Ну, чисто формально, даже "меньше делать бесполезных задач" строго говоря не означает "делать больше полезных" :) В общем, я совершенно согласен с такой постановкой, это было просто небольшое уточнение другими словами - что ответственность за продуктивность остается, и именно достигнутая продуктивность позволяет тимлиду скажем ходить к руководству и просить прибавки команде зарплаты. И в общем-то это все - именно то что меня лично мотивирует в этой работе.
В целом согласен, но лидер это не только про это. Даже это вот желание сделать работу команды более комфортной - это же не получится, если команда работает не эффективно. То есть лидер - это и про ответственность. И за команду, и за проект.
Хм, переносить логику с Oracle на PG - плохая идея.
Ну вообще в сегодняшних реалиях РФ никто не спрашивает обычно. Переносить - это требование государства для некоторых компаний.
Что до конкретных запросов - то у меня лично претензия только к оптимизатору, который несколько ограничен. Логика эта - обычный SQL, с подзапросами, вполне стандартный. Там где специфичная нестандартная оракловая логика не переносится (например, где-то мы активно применяли SCN, и замены ему нифига не видно) - ну какие тут претензии к PG реально могут быть?
А бэкап... ну как бы, вопрос тут скорее к тому, что по документации - можно таблицу 32Тб. А по факту - можно базу 10Тб со скрипом. А до миграции была база примерно 160Тб, и ничего, работала как-то. А сейчас стало 16 * 10.
Ну и да, я прекрасно понимаю, что огромному числу компаний до таких объемов расти и расти, и они ничего такого не заметят вовсе.
Spring Data JPA считается швейцарским ножом для работы с БД в Java.
Да просто статья начинается вот с этого. Кем считается, почему считается? Непонятно, откуда взят данный постулат. Это раз.
И второе, наверное даже более важное: а автор вообще швейцарским ножом пытался когда-нибудь делать серьезную работу? Швейцарский нож - это карманный универсальный инструмент, который плохо делает почти все, что умеет. Хлеб им порезать проблематично, пассатижи там если и бывают - то гавно, отвертка - тоже. Поэтому само сравнение не совсем корректное - если предмет данной статьи делает хорошо хоть что-нибудь - то просто определите для себя, в каких задачах вы его употребляете, а для других задач найдите инструмент более подходящий, благо их существует достаточно много. Даже голый JDBC может быть осмысленным вариантом где-то (хотя я лично остановился на Spring Jdbc Template).
В вопросе речь о совершенно конкретной хорошо определенной функции над json. Которая по сути внутри представляет из себя JsonPath. На план запроса она никак влиять не может. Цена исполнения - C * число строк. Множитель C наверное не константа, это в примере json константой задан, а в реальности он скорее всего будет значением колонки таблицы (т.е. может быть разной структуры и размера). Ну т.е. тут речь скорее всего о том, какова производительность JsonPath на разных JSON и выражениях (которое тут в примере $.name).
Ну давайте я чуть иначе выскажусь - на мой взгляд диаграмма Ганта это просто. И MS Project тоже. До определенного предела конечно - когда вы не занимаетесь рисками, т.е. не считаете вероятности, например. То что вы хотели еще дальше упростить - это все норм.
И когда у вас пять задач - то вероятно вам и критический путь очевиден без диаграммы. Но само понятие критического пути - это ведь тоже просто. Ну т.е. раз уж вы упомянули, что нужно определить зависимости, почему не визуализировать их в виде Ганта?
В общем, мой вопрос - он скорее из области образования. Почему в мое время простых инженеров учили планировать на коленке и рисовать Ганта (MS Project еще не существовал как класс), а нынешних простых разработчиков не учат? Может потому и навыков планирования нет, что не учат базе?
Я бы по четвертому пункту добавил, что формально в постгресе размер таблицы - 32 терабайта, а число таблиц в базе что-то типа миллиона. А де факто у нас в компании рекомендация не делать базу больше 10 терабайт, иначе будут проблемы с бэкапом. В итоге при миграции с оракла на постгрес получается шардированная база из 16 узлов, в то время как в оракле это была одна база, и проблем с бэкапом не было.
Отсутствие hint-ов sql в сочетании с отвратительнейшим оптимизатором:
Ну вообще хинты-то есть, это вы зря. pg_hint_plan вроде звать это расширение, у нас его по умолчанию везде ставят. Детальнее сравнить не возьмусь. А насчет оптимизатора - согласен. При массовой миграции массово же напоролись на то, что запросы, которые оракл прекрасно оптимизировал, стали работать фигово, потому что оптимизатор например не умеет делать push predicate в подзапрос (впрочем, такая же примерно проблема у наших не особо новых версий MS SQL была).
Разработчики не должны создавать таблицы вручную. А если они создаются кодом, как положено, и мигрируют на новую версию тоже кодом (то есть имеет место повторяемость), то трудоемкость написания того, что вы тут показываете, выглядит намного большей, чем трудоемкость написания DDL для самого создания таблиц. Ну т.е. тест должен по сложности примерно соответствовать сложности написания CREATE TABLE, иначе вы замучаетесь его сопровождать.
Ну т.е. сама по себе идея проверять соответствие схемы базы требованиям - она несомненно правильная, но показанное решение выглядит как не слишком гибкое и трудоемкое в разработке. Ну или возможно что я вас не очень понял, вы описали внутренности инструмента, а на самом деле реальные тесты выглядят совсем несложно и пишутся/сопровождаются легко и быстро?
И не БЭСМ-6 ни разу. Алдан...
Составить более детальные требования - это время (и деньги) тимлида. Указать разные веса - тоже самое. Если цель время и деньги тимлида экономить, заставлять его детализировать описание и расставлять веса - нонсенс.
Ну вот в моем случае вообще никогда не нужно 100 попадание в вакансию. Мы вполне готовы брать (и берем) людей, которые дополняют команду. При этом отсутствующие навыки либо дообучаются в работе, либо эту часть работы может сделать другой член команды. В состоянии ли HR (или же ИИ) этот фактор учесть - я не уверен, слишком много контекста ему для этого нужно дать.
Ну, я ваш коммент понял так, что типовой HR тоже не различает эти ключевые слова, раз указали LiquiBase - значит должно быть (а что flyway может быть заменой - не понимаем). И если вы об этом - то я скорее согласен.
Но если уж мы пытаемся белкового заменить на ИИ, то вот эти вот веса или важности ключевым словам не мешало бы попробовать добавить. А то получается матрица компетенций в чистом виде, которая на программистах практически не работает. Ну т.е. она может и работает - если мы имеем дело с типовыми винтиками, но как только что-то нестандартное - так все. И в первую очередь именно потому, что навыков в штуках - кучи, они все разной важности, они связаны друг с другом, и человек это все оценивает достаточно быстро и легко - разумеется речь про скажем тимлида, который и писал описание вакансии, и который понимает, что ну нету в резюме JUnit, зато есть TestNG - ну так и фиг с ним, это одно и тоже.
Что мы тут видим? Мы видим три темы.
LiquiBase это мелкий фреймворк, предназначенный для решения конкретной задачи, не единственный в своей нише (flyway вспоминается на раз-два). Синьору с 10 годами опыта нужно на освоение может пару часов, чтобы начать работать.
SQL - это наоборот, тема необъятная. Во-первых, существует множество версий даже стандарта, которые все время выходят новые (последний вроде 2023, при этом я например стараюсь укладываться в рамки SQL-92). Во-вторых, существует множество даже широко используемых СУБД, которые отличаются в нюансах. И сильно отличаются. На то, чтобы "знать" SQL можно потратить годы, в тоже время скажем базовый курс по нему - это несколько занятий.
опыт работы с СУБД PostgreSQL - ну это примерно как знание SQL, только в более узком смысле. Я думаю тоже можно потратить годы, чтобы скажем стать квалифицированным DBA.
Итого, что в сухом остатке? Предлагается механизм оценки резюме, где три приведенные выше (просто для примера, точно такой же разбор можно провести по остальным пунктам) темы считаются равноценными, в то время как на самом деле они по сложности освоения различаются на порядки. В таком виде все это бессмысленная фигня. Не может оценка 10/10 по LiquiBase стоить столько же, как оценка 2/10 по SQL. Это все еще разница на порядки.
Согласен. Более того, как можно быть ненадежным и непредсказуемым лидером, так и одних надежности и предсказуемости недостаточно, чтобы им стать. То есть, это хорошие для лидера качества, но непосредственно и только благодаря им лидером не становятся.
Ну мне посыл статьи не показался таким уж очевидным. А может сравнение как раз и смутило.
Ну, чисто формально, даже "меньше делать бесполезных задач" строго говоря не означает "делать больше полезных" :) В общем, я совершенно согласен с такой постановкой, это было просто небольшое уточнение другими словами - что ответственность за продуктивность остается, и именно достигнутая продуктивность позволяет тимлиду скажем ходить к руководству и просить прибавки команде зарплаты. И в общем-то это все - именно то что меня лично мотивирует в этой работе.
В целом согласен, но лидер это не только про это. Даже это вот желание сделать работу команды более комфортной - это же не получится, если команда работает не эффективно. То есть лидер - это и про ответственность. И за команду, и за проект.
Честно - не знаю. В моем окружении большинство с техническим, но это все разработчики.
Ну я нарисую, если что :) Но не буду обобщать, я любил начерталку.
Ну вообще в сегодняшних реалиях РФ никто не спрашивает обычно. Переносить - это требование государства для некоторых компаний.
Что до конкретных запросов - то у меня лично претензия только к оптимизатору, который несколько ограничен. Логика эта - обычный SQL, с подзапросами, вполне стандартный. Там где специфичная нестандартная оракловая логика не переносится (например, где-то мы активно применяли SCN, и замены ему нифига не видно) - ну какие тут претензии к PG реально могут быть?
А бэкап... ну как бы, вопрос тут скорее к тому, что по документации - можно таблицу 32Тб. А по факту - можно базу 10Тб со скрипом. А до миграции была база примерно 160Тб, и ничего, работала как-то. А сейчас стало 16 * 10.
Ну и да, я прекрасно понимаю, что огромному числу компаний до таких объемов расти и расти, и они ничего такого не заметят вовсе.
Да просто статья начинается вот с этого. Кем считается, почему считается? Непонятно, откуда взят данный постулат. Это раз.
И второе, наверное даже более важное: а автор вообще швейцарским ножом пытался когда-нибудь делать серьезную работу? Швейцарский нож - это карманный универсальный инструмент, который плохо делает почти все, что умеет. Хлеб им порезать проблематично, пассатижи там если и бывают - то гавно, отвертка - тоже. Поэтому само сравнение не совсем корректное - если предмет данной статьи делает хорошо хоть что-нибудь - то просто определите для себя, в каких задачах вы его употребляете, а для других задач найдите инструмент более подходящий, благо их существует достаточно много. Даже голый JDBC может быть осмысленным вариантом где-то (хотя я лично остановился на Spring Jdbc Template).
В вопросе речь о совершенно конкретной хорошо определенной функции над json. Которая по сути внутри представляет из себя JsonPath. На план запроса она никак влиять не может. Цена исполнения - C * число строк. Множитель C наверное не константа, это в примере json константой задан, а в реальности он скорее всего будет значением колонки таблицы (т.е. может быть разной структуры и размера). Ну т.е. тут речь скорее всего о том, какова производительность JsonPath на разных JSON и выражениях (которое тут в примере $.name).
Ну давайте я чуть иначе выскажусь - на мой взгляд диаграмма Ганта это просто. И MS Project тоже. До определенного предела конечно - когда вы не занимаетесь рисками, т.е. не считаете вероятности, например. То что вы хотели еще дальше упростить - это все норм.
И когда у вас пять задач - то вероятно вам и критический путь очевиден без диаграммы. Но само понятие критического пути - это ведь тоже просто. Ну т.е. раз уж вы упомянули, что нужно определить зависимости, почему не визуализировать их в виде Ганта?
В общем, мой вопрос - он скорее из области образования. Почему в мое время простых инженеров учили планировать на коленке и рисовать Ганта (MS Project еще не существовал как класс), а нынешних простых разработчиков не учат? Может потому и навыков планирования нет, что не учат базе?
Так я вам ровно о том, что и в Москве не было никакого изобилия.
StreamGate. SIDEC. Не уверен, что и то и другое можно даром, но в целом они уже близки к GG оба. Не opensource ни разу. Но ведь и OGG тоже же не.
Я бы по четвертому пункту добавил, что формально в постгресе размер таблицы - 32 терабайта, а число таблиц в базе что-то типа миллиона. А де факто у нас в компании рекомендация не делать базу больше 10 терабайт, иначе будут проблемы с бэкапом. В итоге при миграции с оракла на постгрес получается шардированная база из 16 узлов, в то время как в оракле это была одна база, и проблем с бэкапом не было.
Ну вообще хинты-то есть, это вы зря. pg_hint_plan вроде звать это расширение, у нас его по умолчанию везде ставят. Детальнее сравнить не возьмусь. А насчет оптимизатора - согласен. При массовой миграции массово же напоролись на то, что запросы, которые оракл прекрасно оптимизировал, стали работать фигово, потому что оптимизатор например не умеет делать push predicate в подзапрос (впрочем, такая же примерно проблема у наших не особо новых версий MS SQL была).
А что в нем тяжелого? Это просто функция, выполняемая на каждой строке результата. Ну будет потреблять сколько-то процессора. Как любая функция.
Регулярно. Причем были очень масштабные, затронувшие сотни экземпляров баз. И да, это именно постгрес.
Для первого курса это было очень смело. Это я вам как выпускник кафедры 601 МАИ могу смело сказать.