Мучаюсь проблемой выбора. Есть у кого опыт использования? Что посоветуете?

Здравствуйте, garrick, Вы писали:

G>Мучаюсь проблемой выбора. Есть у кого опыт использования? Что посоветуете?
А что они разве сильно пересекаются? Используй оба!
DbUtils там вообще много всего, и многое из этого всего далеко не всегда нужно.

Я ещё понимаю мучительный выбор между myBatis и Hibernate. DbUtils и JDBCTemplate это две примитивные утилиты. Используйте обе.

Здравствуйте, Blazkowicz, Вы писали:


B>А что они разве сильно пересекаются? Используй оба!
B>DbUtils там вообще много всего, и многое из этого всего далеко не всегда нужно.

Мне казалось у них почти идентичный функционал. И то и другое это более высокоуровневая обёртка над JDBC. Разве не так?

B>Я ещё понимаю мучительный выбор между myBatis и Hibernate. DbUtils и JDBCTemplate это две примитивные утилиты. Используйте обе.

Зачем обе? В том то и проблема — надо выбрать что-то одно. Задача — "синхронизация" баз разных типов. Lotus Notes и Oracle.

Здравствуйте, Blazkowicz, Вы писали:

B>Я ещё понимаю мучительный выбор между myBatis и Hibernate. DbUtils и JDBCTemplate это две примитивные утилиты. Используйте обе.

Как-то не понятен ваш ответ. Вроде всё с точностью до наоборот. Выбор между myBatis и Hibernate — не мучителен. Это продукты совершенно разного веса и категории. Стало быть выбор делается не с точки зрения какой из них лучше, а с точки зрения желаемого уровня абстракции работы с БД, который мы хотим иметь в своём проекте.

А вот DbUtils и JDBCTemplate похоже как раз продукты совершенно одного уровня. К чему их использовать оба, если их цель совершенно одинакова — дать лёгкую обёртку над JDBC классами дабы добавить немного комфорта и избежать ошибок освобождения ресурсов?

Ответить на стартовый вопрос внятно не могу, ибо никогда не использовал DbUtils. А вот Spring JDBCTemplate пользую регулярно и никаких проблем с ним не было. Посему и не искал добра от добра.

Здравствуйте, garrick, Вы писали:

G>Мне казалось у них почти идентичный функционал. И то и другое это более высокоуровневая обёртка над JDBC. Разве не так?
Нет, это не "высокоуровневая обертка", а просто удобная обертка для работы с JDBC API. Не более.

G>Зачем обе?
Затем что они, вроде, по функциональности не сильно пересекаются. Зачем Spring делать копию Apache Commons, если они могут просто использовать Apache Commons?

G>В том то и проблема — надо выбрать что-то одно.
Они на столько примитивны, что за 3-4 часа можно ознакомится со всей документацией и выбрать что-то что больше понравиться.
Никаких общих абсолютных критериев сравнения для них нет. Могу только сказать что в DbUtils больше всего. Но это мелкие утилитарные решения. Они вам не заменят целый фреймверк.

G>Задача — "синхронизация" баз разных типов. Lotus Notes и Oracle.
Для Lotus Notes уже есть JDBC драйвер? Задачу "синхронизация" можно и на Hibernate успешно решать.

Здравствуйте, garrick, Вы писали:

Обрати так же внимание, что на указаных двух решениях свет клином не сошелся.
Есть куча альтернатив
http://stackoverflow.com/a/18672009
Ну, и myBatis, QueryDSL и Hibernate тоже вполне можно использовать.

Здравствуйте, Steamus, Вы писали:

S>Выбор между myBatis и Hibernate — не мучителен.
Ну, тогда, пожалуйста, перечисли критерии которые бы я мог использовать чтобы выбрать один из этих двух?

S>А вот DbUtils и JDBCTemplate похоже как раз продукты совершенно одного уровня.
S>ибо никогда не использовал DbUtils
Если ты никогда не использовал, то откуда ты знаешь? То что они примерно одного уровня ещё не значит что они взаимозаменяемы.

Здравствуйте, Blazkowicz, Вы писали:


B>Нет, это не "высокоуровневая обертка", а просто удобная обертка для работы с JDBC API. Не более.
Ну, да. Я это и имел ввиду.

B>Затем что они, вроде, по функциональности не сильно пересекаются. Зачем Spring делать копию Apache Commons, если они могут просто использовать Apache Commons?
Мне показалось... надо посмотреть ещё раз внимательнее.

B>Для Lotus Notes уже есть JDBC драйвер? Задачу "синхронизация" можно и на Hibernate успешно решать.
Нет. Lotus Notes нереляционная база, JDBC нету. SELECT/INSERT/UPDATE будет только для Oracle, для Lotus — своё API.
На Hibernate cделать последовательную быструю вставку в Oracle порядка миллиона записей нормально? Тормозов не будет?

Здравствуйте, garrick, Вы писали:

G>На Hibernate cделать последовательную быструю вставку в Oracle порядка миллиона записей нормально? Тормозов не будет?
Не, знаю что там в 4м, но жалобы были на StatelessSession пару лет назад. Тормозов не будет, если уметь пользоваться.
Просто смысл в том, что когда у вас между одной базой и другой, нужно ещё произвести кучу преобразований. То, возможно, проще всего, загрузить в объекты. Сконвертировать их согласно правилам. И сохранить новые объекты. Конечно, будет немного медленне. Но зато будет достаточно просто менять логику преобразования одной структуры в другую.

Но! Меня больше всего смущает вопрос "а на кой в этой задаче Java вообще"? Если на преобразовании одних структур в другие нет никакой развесистой логики, то для чего Java? У Oracle разве нет других инструментов чтения из Lotus Notes?

Здравствуйте, garrick, Вы писали:

B>>Для Lotus Notes уже есть JDBC драйвер? Задачу "синхронизация" можно и на Hibernate успешно решать.
G>Нет. Lotus Notes нереляционная база, JDBC нету. SELECT/INSERT/UPDATE будет только для Oracle, для Lotus — своё API.
G>На Hibernate cделать последовательную быструю вставку в Oracle порядка миллиона записей нормально? Тормозов не будет?
Ещё меня смущает комбинцаия "синхронизация" и "миллион записей". "Синхронизация" подразумевает поддержку одного и того же состояния в обоих БД.
А быстрая вставка "миллиона записей", это ведь единоразовая акция? Просто для миграции? Или на какой-то регулярной основе?

Здравствуйте, Steamus, Вы писали:

S>А вот DbUtils и JDBCTemplate похоже как раз продукты совершенно одного уровня. К чему их использовать оба, если их цель совершенно одинакова — дать лёгкую обёртку над JDBC классами дабы добавить немного комфорта и избежать ошибок освобождения ресурсов?

Именно это собственно и требуется. Смотрел описания на сайте Apache и Spring, судя по ним продукты имеют абсолютно одинаковое целевое назначение и практически одинаковый, очень похожий, интерфейс вызова SELECT/INSERT/UPDATE, открытия закрытия соединений и пр. DbUtils более компактный. JDBC Template имеет возможность к расширению, как в функциональном плане, так и в физическом (в мегабайтах библиотек) за счёт включения других модулей Spring. Так же нашел в Spring упоминание о возможности работы с хранимыми процедурами. Возможно в DbUtils это тоже есть, но на сайте я не увидел упоминания об этом.
В данном проекте на первом плане производительность, т.к. объёмы данных очень большие, и компактность т.к. всё это надо запустить в среде Lotus Notes, а там есть свои ограничения прибабахи.

Здравствуйте, Blazkowicz, Вы писали:


B>Но! Меня больше всего смущает вопрос "а на кой в этой задаче Java вообще"? Если на преобразовании одних структур в другие нет никакой развесистой логики, то для чего Java? У Oracle разве нет других инструментов чтения из Lotus Notes?

1. Преобразования есть.
2. Да, Oracle не умеет залазить в базу Lotus Notes, да и вообще, по-моему, никто не умеет. База нереляционная — селекты, инсёрты в ней не работают, она вообще SQL ни в каком виде не понимает.

Здравствуйте, garrick, Вы писали:

G>1. Преобразования есть.
Их удобно реализовать на Java объектах?

G>2. Да, Oracle не умеет залазить в базу Lotus Notes, да и вообще, по-моему, никто не умеет. База нереляционная — селекты, инсёрты в ней не работают, она вообще SQL ни в каком виде не понимает.
Ну, я не знаю. Гугл массу рецептов предлагает
http://www.lialis.com/lotussolutionprovider.nsf/pages/converttosql

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, garrick, Вы писали:

B>Ещё меня смущает комбинцаия "синхронизация" и "миллион записей". "Синхронизация" подразумевает поддержку одного и того же состояния в обоих БД.
B>А быстрая вставка "миллиона записей", это ведь единоразовая акция? Просто для миграции? Или на какой-то регулярной основе?

На регулярной. Т.к. как я уже говорил база нереляционная, никакая отчётная система не умеет с ней работать, а своей тоже нету. Поэтому много данных ежедневно сливается в Oracle, откуда в дальнейшем формируются различные аналитические отчёты. Но это одна сторона вопроса. Так же необходима и синхронизация различных данных между разными системами часть их которых написаны в Lotus Notes, часть в Oracle — тут конечно уже не миллионы записей, а поскромнее немного. Сейчас всё это хозяйство работает на голом JDBC, но часто приходится что-то "допиливать", то добавить, то убавить. Хотел этот JDBC как-то облагородить, что бы красивше и удобнее было.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Steamus, Вы писали:

S>>Выбор между myBatis и Hibernate — не мучителен.
B>Ну, тогда, пожалуйста, перечисли критерии которые бы я мог использовать чтобы выбрать один из этих двух?

Легко.
Hibernate — громоздский и достаточно выскоуровневый ORM. Позволяет работать с БД даже не зная слова SQL и таблица. И танцевать прямо от структуры бизнес объектов не думая как они там будут уложены в реляционную модель. Он даже и таблицы сам создаст и запросы напишет. Хорош для ускорения и упрощения реализации проектов, требующих относительно несложной БД (пусть даже и с большим количеством таблиц). В случае изощрённой БД может потребовать достаточно сложного тьюнинга и ручного написания запросов. И, как следствие, выскоквалифицированного эксперта не только в базах данных, но и в самом ORM.

myBatis — легковесный ORM. Никакого интеллектуального сокрытия автоматически не делает. Он лишь даёт способ элегантно вынести все запросы во внешние файлы и с помощью шаблонизатора определить маппинг между результатами запросов и вашими бизнес объектами. Это часто довольно удобно. Опять же, скорость работы с БД практически не страдает и она находится полностью под вашим контролем. Слово SQL надо знать хорошо. Сам не раз использовал ещё в те времена когда он назывался iBatis.

S>>А вот DbUtils и JDBCTemplate похоже как раз продукты совершенно одного уровня.
S>>ибо никогда не использовал DbUtils
B>Если ты никогда не использовал, то откуда ты знаешь? То что они примерно одного уровня ещё не значит что они взаимозаменяемы.

Когда люди говорят, что два продукта предназначены для одной цели и есть примерно одного уровня, то семантически, в языке, это как раз и означает, что для большинства задач они должны быть взаимозаменяемы. С теми или иными преимуществами в удобстве/скорости/чём-то ещё...

То что я никогда не использовал некий продукт, ещё не означает, что я не умею читать и не способен просмотреть его программный интерфейс и примеры использования. И этот анализ показал, что это продукты действительно одного уровня. С другой стороны, если я не использовал продукт, я не знаю о его скрытых ошибках, производительности и прочее, чего не всегда можно получить из документации.

Скажем, в DbUtils меня бы смутило то, что последний официальный релиз был полтора года назад. Это, несомненно, может говорить о том, что продукт окончательно достиг своего совершенства и сияющей вершины. Но также это может говорить и о том, что он несколько поднадоел своим создателям и они потеряли интерес к его развитию.

Здравствуйте, Steamus, Вы писали:

S>Легко.
В целом ни о чем. Я говорил о критериях выбора. А не об отличиях.

S>Hibernate — громоздский и достаточно выскоуровневый ORM.
Верно.

S>Позволяет работать с БД даже не зная слова SQL и таблица.
Заблуждение и преувеличение.

S>И танцевать прямо от структуры бизнес объектов не думая как они там будут уложены в реляционную модель.
Ещё одно заблуждение. Я точно так же другими инструментами могу сделать кривую реляционную модель. Это к Hibernate отношения не имеет.

S>Он даже и таблицы сам создаст и запросы напишет.
Заблуждение. Инструмент hql2ddl не жизнеспособен вне прототипизирования. И запросы hibernate сам не напишет. Он их выводит из маппинга и параметров заданных разработчиком.

S>Хорош для ускорения и упрощения реализации проектов, требующих относительно несложной БД (пусть даже и с большим количеством таблиц).
Заблуждение. Сложность БД к использованию Hibernate отношения не имеет. Hibernate как раз упрощает работу с огромными деревьями ассоциаций. И чем больше у вас ассоциаций, тем проще их контролировать.
Несколько SELECT превратить в JOIN и обратно одними только флагами.

S>В случае изощрённой БД может потребовать достаточно сложного тьюнинга и ручного написания запросов.
Какого например "сложного тьюнинга"? И какую именно проблему может решить ручной запрос? Производительности? Сильно сомневаюсь.

S>И, как следствие, выскоквалифицированного эксперта не только в базах данных, но и в самом ORM.
Без квалифицированого эксперта БД ORM — бесполезный инструмент. И да, это актуальня проблема в том что ORM сложный инструмент. То есть если мне влом освоить сложный инструмент, то стоит брать простой? Или как?

S>myBatis — легковесный ORM. Никакого интеллектуального сокрытия автоматически не делает. Он лишь даёт способ элегантно вынести все запросы во внешние файлы и с помощью шаблонизатора определить маппинг между результатами запросов и вашими бизнес объектами. Это часто довольно удобно. Опять же, скорость работы с БД практически не страдает и она находится полностью под вашим контролем. Слово SQL надо знать хорошо. Сам не раз использовал ещё в те времена когда он назывался iBatis.
Что такое myBatis я и так знаю. Критериев выбора между этими двумя ORM пока не увидел.

S>Когда люди говорят, что два продукта предназначены для одной цели и есть примерно одного уровня, то семантически, в языке, это как раз и означает, что для большинства задач они должны быть взаимозаменяемы. С теми или иными преимуществами в удобстве/скорости/чём-то ещё...
Они одного уровня, это значит что они являются обертками над JDBC API. Удобными, но достаточно примитивными чтобы было очевидно как они используют JDBC API.
На этом сходство заканчиваются. Набор фич у DBUtils и Spring JDBC пересекается слабо. Поэтому достаточно заглянуть а мануал. Найти фичи, которые тебе нужны и сделать выбор.

S>Скажем, в DbUtils меня бы смутило то, что последний официальный релиз был полтора года назад.
Spring JDBC за последние 2 года сильно поменялся? Какие-то новые фичи добавились? Подозреваю что нет.

S>Это, несомненно, может говорить о том, что продукт окончательно достиг своего совершенства и сияющей вершины. Но также это может говорить и о том, что он несколько поднадоел своим создателям и они потеряли интерес к его развитию.
DBUtils достаточно древний проект. С появлением Hibernate и iBatis он стал никому не интересен. Подходит только там где уже есть куча кода работающего с JDBC и его можно упростить.

Здравствуйте, Blazkowicz, Вы писали:

S>>Легко.
B>В целом ни о чем. Я говорил о критериях выбора. А не об отличиях.

S>>Hibernate — громоздский и достаточно выскоуровневый ORM.
B>Верно.

S>>Позволяет работать с БД даже не зная слова SQL и таблица.
B>Заблуждение и преувеличение.

...

В принципе, можно вести дискуссию ещё более аргументированно и авторитетно. Для этого, помимо дробления смысловых абзацев на отдельные предложения, рекомендую практиковать также и дробление предложений на отдельные слова и знаки препинания. И затем уж, независимо комментировать каждый лексический элемент. Это более ярко демонстрирует глубину понимания вопроса и тщательность проработки мысли.

Здравствуйте, Steamus, Вы писали:

S>В принципе, можно вести дискуссию ещё более аргументированно и авторитетно. Для этого, помимо дробления смысловых абзацев на отдельные предложения, рекомендую практиковать также и дробление предложений на отдельные слова и знаки препинания. И затем уж, независимо комментировать каждый лексический элемент. Это более ярко демонстрирует глубину понимания вопроса и тщательность проработки мысли.
Ну, понятно. Когда по теме сказать нечего начинаюся обсуждение отстраненных вещей к теме отношения не имеющих. Удачи!

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Steamus, Вы писали:

S>>В принципе, можно вести дискуссию ещё более аргументированно и авторитетно. Для этого, помимо дробления смысловых абзацев на отдельные предложения, рекомендую практиковать также и дробление предложений на отдельные слова и знаки препинания. И затем уж, независимо комментировать каждый лексический элемент. Это более ярко демонстрирует глубину понимания вопроса и тщательность проработки мысли.
B>Ну, понятно. Когда по теме сказать нечего начинаюся обсуждение отстраненных вещей к теме отношения не имеющих. Удачи!

Да, мне сложно вести с вами дискуссию по теме. Вы с одной стороны говорите очень много умных слов, а с другой — выдаёте перлы вида: Удобными, но достаточно примитивными чтобы было очевидно как они используют JDBC API... Я вообще это осмыслить не могу. Так достаточно примитивны или недостаточно? Если они достаточно примитивны, тогда почему не очевидно? Или у вас слово примитивный также имеет своё уникальное значение, как и "невзаимозаменяемые продукты одной цели и одного уровня".

Мудрые советы использовать зачем-то две, по сути и уровню, одинаковых библиотеки в одном проекте даже обсуждать не хочется. Туманно всё в общем. Хотя и выглядит умнО. Удачи!

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Blazkowicz, Вы писали:

B>>Здравствуйте, Steamus, Вы писали:

S>>>В принципе, можно вести дискуссию ещё более аргументированно и авторитетно. Для этого, помимо дробления смысловых абзацев на отдельные предложения, рекомендую практиковать также и дробление предложений на отдельные слова и знаки препинания. И затем уж, независимо комментировать каждый лексический элемент. Это более ярко демонстрирует глубину понимания вопроса и тщательность проработки мысли.
B>>Ну, понятно. Когда по теме сказать нечего начинаюся обсуждение отстраненных вещей к теме отношения не имеющих. Удачи!

А>Да, мне сложно вести с вами дискуссию по теме. Вы с одной стороны говорите очень много умных слов, а с другой — выдаёте перлы вида: Удобными, но достаточно примитивными чтобы было очевидно как они используют JDBC API... Я вообще это осмыслить не могу. Так достаточно примитивны или недостаточно? Если они достаточно примитивны, тогда почему не очевидно? Или у вас слово примитивный также имеет своё уникальное значение, как и "невзаимозаменяемые продукты одной цели и одного уровня".

А>Мудрые советы использовать зачем-то две, по сути и уровню, одинаковых библиотеки в одном проекте даже обсуждать не хочется. Туманно всё в общем. Хотя и выглядит умнО. Удачи!

Выше пост мой. Извиняюсь, разлогинился.