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

Question

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

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

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

Это по существу сводится к:

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

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

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

Спасибо,

Джон

Answer 1

Род Джонсон в своем "J2EE Design ВОПОГ развития", написал очень четкий анализ о ORM/StoredProcedures. Он сказал, что

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

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

Answer 2

«СДО - будет медленнее, чем ЗЛ (но большинство поддержки пейджинга)»

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

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

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

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

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

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

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

Answer 3

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

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