Хранимые процедуры и JDO для проекта хранилища данных

Question

В старые времена мы использовали для доступа к базе данных с помощью хранимых процедур. Их рассматривали как «лучший» способ управления данными. Мы храним данные в базе данных, и любой язык / платформа может получить к ним доступ через JDBC / ODBC / и т. Д.

Тем не менее, в последние годы стали популярными такие механизмы поиска хранилищ, основанные на отражении / метаданных, как Hibernate / DataNucleus. Первоначально мы волновались, что они будут медленными из-за дополнительных шагов (рефлексия дорогая) и того, как они извлекают ненужные данные (весь объект), когда все, что нам нужно, это одно поле.

Я начинаю планировать большой проект хранилища данных, использующий J2EE, но я немного не уверен, стоит ли переходить на хранимые процедуры или JDO / JPA и тому подобное. Недавно я работал с Hibernate, и, честно говоря, я не скучаю по написанию хранимых процедур CRUD!

По сути, это сводится к:

Хранимые процедуры
+ Может быть оптимизирован на сервере (хотя только запросы)
- Вероятно, для каждой таблицы будет более тысячи хранимых процедур: добавление, удаление, обновление, getById и т. Д.

JDO
+ Я не буду тратить следующие несколько месяцев на написание параметров.add ("@ firstNames", customer.getFirstName ()); ...
- Будет медленнее, чем SP (но большинство поддерживает пейджинг)

Чего бы ты хотел в моей ситуации? В этом случае я думаю, что это очень много.

Спасибо

John

Answer 1

"JDO - будет медленнее, чем SP (но большинство поддерживает подкачку страниц)"

Это предположение часто ложно. У SP нет причин быть особенно быстрым. Я сделал некоторые измерения, и они не быстрее, чем код за пределами базы данных.

Хранилище данных характеризуется загрузками только для вставки и длительными SELECT...GROUP BY... запросами.

Вы не пишете обработку транзакций OLTP. Вы не используете 3NF как способ предотвращения аномалий обновления при транзакциях обновления / удаления.

Поскольку вы выполняете массовую вставку, SP определенно будет работать медленнее, чем утилита массовой загрузки. Массовые загрузчики часто являются многопоточными и потребляют все доступные ресурсы ЦП. SP является частью БД и может использовать только ограниченные ресурсы БД.

Поскольку вы в основном делаете SELECT GROUP BY, SP здесь тоже не сильно поможет. Оператор SELECT не получает преимущества от включения в процедуру.

Тебе они не нужны. Они не помогают

Вы можете легко сравнить массовую загрузку и запрос, чтобы продемонстрировать, что SP не помогают.

Answer 2

Род Джонсон в своей «J2EE Design adn Development» написал очень четкий анализ об ORM / StoredProcedures. Он сказал, что

Хранимые процедуры должны использоваться только в системе J2EE для выполнения операций, которые всегда будут интенсивно использовать базу данных, независимо от того, реализованы они в базе данных или в коде Java, который обменивается большим количеством данных с базой данных.

Поскольку вы планируете внедрить хранилище данных, я думаю, что подход с использованием хранимых процедур является правильным выбором.

Answer 3

Я бы предложил использовать метаданные для генерации сценариев, которые вы используете для загрузки в хранилище данных. Это позволяет вам получить выигрыш в производительности от использования специализированных инструментов загрузки и, возможно, от хранимых процедур (если вы используете достаточно древнюю базу данных). Кроме того, вы, вероятно, в конечном итоге закодируете хотя бы немного SQL. Выполнение общих сценариев в качестве хранимых процедур позволит вам планировать все их одинаково и не беспокоиться об изменении их вызова при переписывании сгенерированного кода, чтобы он работал лучше.

Что касается вывода данных, если то, что вы создаете в J2EE, является инструментом отчетности, тогда вам лучше использовать JDO. Хотя я не очень хорошо знаком с аспектами отчетности, я вижу одно преимущество: вам будет проще позволить вашим конечным пользователям создавать пользовательские отчеты, которые вы не ожидали заранее (хотя вы все равно должны иметь некоторые ограничения на то, что они могут сделать, чтобы они не удаляли базу данных в процессе).