В целом, публикация хорошая. Однако для полноты статьи было бы полезно упомянуть "перемежение". Оно только вскользь упоминается в начале статьи, и на этом всё. Как ни крути, а "перемежение" оказывает серьёзное влияние на корректирующие способности кода Рида-Соломона.
Также можно было бы упомянуть об избыточности кода, о том, какие параметры кода Рида-Соломона влияют на её величину, и в целом о роли избыточности в улучшении исправления ошибок. Но это уже не столь критично. Думаю, что те, кто сталкивался с "помехоустойчивым кодированием", так или иначе встречались с понятием избыточности.
Думаю, что если у вас есть желание написать подобную статью, то не стоит себя останавливать. Я показал свои варианты реализации хранения деревьев в БД, а вы покажите свои. Соглашусь, что ORM Hibernate не идеальный фреймворк для работы с деревьями, но и реляционные БД тоже не заточены для работы с ними. Одна из причин использования нативных SQL запросов - это ограниченные и не всегда эффективные возможности самого ORM Hibernate. К примеру на данный момент Hibernate не генерирует рекурсивные запросы, а также этот запрос пока нельзя сделать с помощью JPQL. Если полагаться только на средства\возможности Hibernate, то при обходе дерева (Adjacency List) фреймворк сгенерирует множество SQL запросов, когда можно было бы решить эту задачу одним рекурсивным запросом. К тому же, я не вижу каких-либо проблем в использовании нативных SQL запросов, так как этот язык стандартизирован и если придерживаться ANSI стандарта, то не будет проблем с переносимостью в будущем, если возникнет необходимость поменять РСУБД. Полагаться же безукоризненно на ORM фреймворк и не использовать SQL - это тоже не саммый лудший подход, так как фреймворки тоже не идеальны. В статье, я приводил SQL запросы и они местами получились громоздкими, так как я старался сделать так, чтоб произвести операцию (получение потомков, получение родителей, добавления узла и т.д) над деревом минимальным числом запросов в БД и при этом подсчитывать ещё и уровень вложенности. Если громоздкие запросы разбить и обернуть в функции PostgreSQL, то естественно читабельность кода улучшиться, но я не старался привязыватся только к конкретной БД PostgreSQL, поэтому и представил всё SQL запросами. Чиатель же может взять SQL запрос и в зависимости от БД обернуть в функцию PostgreSQL или хранимую процедуру Sybase ASE или же оставить в ввиде именнованого SQL запроса, как в статье. Не отрицаю, что при детальном просмотре запросов, возможно где-то можно сделать улучшения, повысить читабельность. В целом же не вижу каких-либо препятствий или ограничений, если будет несколько статей на подобную тематику. Возможно ваши варианты реализации будут лучше. К тому же, всегда хорошо, если есть несколько вариантов решений подобных задач, будет из чего выбрать:).
Да, вы правы. Но к сожалению не все реляционные СУБД обладают такими решениями для работы с деревьями. В статье, я не старался привязываться к особенностям и возможностям конкретной РСУБД. К тому же для работы с ltree используются специфичные функции и запросы, которые больше напоминают регулярные выражения, а не SQL в чистом виде, который в отличии от lquery стандартизирован. Использование же не стандартизированных функций и выражений может привести к проблемам с переносимостью в будущем, если возникнет необходимость поменять РСУБД. Если же требований в обеспечении переносимости нет, то можно использовать весь имеющийся функционал предоставляемый конкретной РСУБД по максимуму. А специфичные функции и выражения РСУБД, которые могут не поддерживаться конкретным ORM фреймворком можно всегда отправлять на прямую, либо просто отключив проверку синтаксической корректности (для ORM HIBERNATE в конфигурационном файле property hibernate.query.startup_check установить в false).
Я так понимаю отказаться от Lazy имеется ввиду заменить на EAGER. Да, загрузится дерево, но для этого ORM Hibernate сгенерирует множество SQL запросов, чтоб загрузит все связанные узлы потомки, что будет неэффективно, как по количеству отправленных запросов в БД, так и затраченному на всё это времени. И к тому же, если установлен EAGER, Hibernate будет всегда загружать все связанные узлы, а это ещё и большие затраты по памяти.
В статье, я не старался заострять внимание конкретно на размере пакета, так как здесь нужно учитывать много факторов: железо, нагрузка на БД, пропускная способность сети и т.д. Эта тема не простая и возможно заслуживает отдельного поста. Да, всё это нужно замерять и в итоге выбрать оптимальное значение размера пакета. Также нужно учитывать такой момент, что в разное время суток и даже в разные дни нагрузка на БД может меняться, если конечно с БД работает не только один сервис загружающий пакетами данные. Если взять какие-либо высоконагруженные онлайн сервисы использующие БД к примеру интернет магазин, интернет-банкинг, сервисы доставки и т.д., то там нагрузка может меняться во времени и это нужно тоже учитывать. Цель же была рассказать о самой пакетной обработке в целом с примерами, вариантами реализации и осветить некоторые важные моменты на которые стоит обратить внимание.
В целом, публикация хорошая. Однако для полноты статьи было бы полезно упомянуть "перемежение". Оно только вскользь упоминается в начале статьи, и на этом всё. Как ни крути, а "перемежение" оказывает серьёзное влияние на корректирующие способности кода Рида-Соломона.
Также можно было бы упомянуть об избыточности кода, о том, какие параметры кода Рида-Соломона влияют на её величину, и в целом о роли избыточности в улучшении исправления ошибок. Но это уже не столь критично. Думаю, что те, кто сталкивался с "помехоустойчивым кодированием", так или иначе встречались с понятием избыточности.
Думаю, что если у вас есть желание написать подобную статью, то не стоит себя останавливать. Я показал свои варианты реализации хранения деревьев в БД, а вы покажите свои. Соглашусь, что ORM Hibernate не идеальный фреймворк для работы с деревьями, но и реляционные БД тоже не заточены для работы с ними. Одна из причин использования нативных SQL запросов - это ограниченные и не всегда эффективные возможности самого ORM Hibernate. К примеру на данный момент Hibernate не генерирует рекурсивные запросы, а также этот запрос пока нельзя сделать с помощью JPQL. Если полагаться только на средства\возможности Hibernate, то при обходе дерева (Adjacency List) фреймворк сгенерирует множество SQL запросов, когда можно было бы решить эту задачу одним рекурсивным запросом. К тому же, я не вижу каких-либо проблем в использовании нативных SQL запросов, так как этот язык стандартизирован и если придерживаться ANSI стандарта, то не будет проблем с переносимостью в будущем, если возникнет необходимость поменять РСУБД. Полагаться же безукоризненно на ORM фреймворк и не использовать SQL - это тоже не саммый лудший подход, так как фреймворки тоже не идеальны. В статье, я приводил SQL запросы и они местами получились громоздкими, так как я старался сделать так, чтоб произвести операцию (получение потомков, получение родителей, добавления узла и т.д) над деревом минимальным числом запросов в БД и при этом подсчитывать ещё и уровень вложенности. Если громоздкие запросы разбить и обернуть в функции PostgreSQL, то естественно читабельность кода улучшиться, но я не старался привязыватся только к конкретной БД PostgreSQL, поэтому и представил всё SQL запросами. Чиатель же может взять SQL запрос и в зависимости от БД обернуть в функцию PostgreSQL или хранимую процедуру Sybase ASE или же оставить в ввиде именнованого SQL запроса, как в статье. Не отрицаю, что при детальном просмотре запросов, возможно где-то можно сделать улучшения, повысить читабельность. В целом же не вижу каких-либо препятствий или ограничений, если будет несколько статей на подобную тематику. Возможно ваши варианты реализации будут лучше. К тому же, всегда хорошо, если есть несколько вариантов решений подобных задач, будет из чего выбрать:).