спящий объект и физическая модель базы данных

Question

Есть ли реальная проблема - например, производительность - когда объектная модель гибернации и физическая модель базы данных больше не совпадают? Есть проблемы? Должны ли они быть синхронизированы?

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

Обновление 20090331
Из приведенных ниже комментариев Пита - проблема была связана с отношениями таблица / данные на уровне данных и на уровне объектов. Если между этими двумя нет никаких зависимостей, то нет никаких падений производительности, если эти отношения не совпадают? Это правильно?

Проблема, с моей точки зрения, заключается в том, что команда разработчиков тратит много времени на «настройку» спящих запросов / объектов, но ничего на уровне базы данных для повышения производительности приложения. Я бы предположил, что они настроятся на оба слоя.

Могут ли эти проблемы возникать из-за плохого начального дизайна базы данных, с которого пытались покрыть / компенсировать разницу с помощью Hibernate?

(я новичок в этом проекте, поэтому играю в догонялки)

Answer 1

Обновление: в ответ на комментарий: НЕОБХОДИМО, чтобы база данных была оптимизирована в дополнение к использованию Hibernate. Когда вы думаете об этом, после всего, что делает hibernate, в конце концов, он просто запрашивает базу данных. Если база данных работает плохо (неправильные или отсутствующие индексы, плохо настроенные табличные пространства и т. Д.), Не имеет значения, насколько сильно вы настраиваете Hibernate. С другой стороны, если ваша база данных настроена хорошо, а Hibernate - нет (возможно, кеширование не настроено должным образом и т. Д., И вы возвращаетесь к базе данных намного больше, чем нужно), тогда производительность будет снижаться по мере Что ж. Всегда важно настроить систему из конца в конец, но начните с основы (базы данных) и работайте.

Окончание обновления

Мне любопытно, что вы имеете в виду под словом "не совпадать" - вы имеете в виду столбцы, добавленные в таблицы, которые не представлены в объектах данных в спящем режиме? Таблицы были добавлены? Я не думаю, что что-то подобное повлияет на производительность (более вероятно, целостность данных, если вы не вставляете / обновляете все столбцы)

Как правило, цель объектной модели НЕ должна соответствовать дословно схеме базы данных. Вы хотите абстрагировать сложность / объединение / нормализацию базовых данных, в этом весь смысл использования чего-то вроде Hibernate.

Так, например, скажем, у вас есть (очень простые вещи) «заказы» и «заказы», ​​

код вашего приложения должен быть в состоянии сделать что-то вроде

order.getItems ()

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

Если это не отвечает на ваш вопрос, пожалуйста, предоставьте более подробную информацию

Answer 2

Возможно, что описанные вами изменения могут вызвать проблемы с производительностью. Я бы подумал, что это должно было быть частью спецификации проекта.
Поэтому, когда вы кодируете его, вы учитываете критерии производительности.

Единственный способ узнать это - загрузить данные в тестовую среду и запустить несколько тестов.

Это должно быть определенно сделано перед выходом в эфир, поскольку это может дать довольно интересные результаты.

Answer 3

Конечно, вы можете закодировать свой уровень абстракции в asm - «может» (ужасное слово для разработчика) будет быстрее.

Это преждевременная оптимизация - возможно, нарушение чистой схемы проекта.

Как и в hibernate-manual - оптимизация может выглядеть по-разному - простое кодирование некоторых частей «может» быть частью этого.