Как часто происходят изменения базы данных или схемы, когда приложение поступает в производство?
Это не имеет значения для вашей рассматриваемой проблемы.Количество изменений в схемах базы данных не имеет значения.Важно то, что ваша модель базы данных может обслуживаться, насколько хорошо она была разработана.Большинство бизнес-приложений увидят множество изменений, если не будет проведено достаточное тестирование производительности, что, к сожалению, верно для большинства приложений.
Если вы пишете типичное бизнес-приложение, яможно ожидать, что какая-то форма кругового проектирования между объектной моделью и моделью базы данных возникнет в процессе разработки.Ваши администраторы баз данных должны владеть и хорошо знать модель базы данных, чтобы они могли помочь или выполнить точную настройку запросов, выдаваемых вашей средой ORM.При этом следует помнить, что вы не можете полагаться только на запросы, выданные платформой ORM.Все изменения должны быть предпочтительно выполнены и протестированы в средах разработки и тестирования интеграции (и, возможно, UAT, если у вас есть) перед его развертыванием в производстве, и, как подсказывает здравый смысл, все изменения будут находиться под контролем версий.
Что касается привязки запросов к базе данных, то это решение, которое должен принять ваш бизнес.Если вы поддерживаете несколько баз данных, вам следует протестировать против всех.Кроме того, вы должны иметь возможность предоставлять разные дистрибутивы для поддержки разных баз данных;это станет проще, если вы поместите свои собственные запросы в специфичные для базы данных файлы orm.xml, такие как orm-oracle.xml, orm-mysql.xml и т. д., и переименуете файлы в orm.xml перед подготовкой распространения.Использование Maven или Ant сделает предлагаемое изменение простым для реализации.
Есть ли другой способ повысить производительность?Производительность очень важна для этого приложения.
Это будет зависеть от того, насколько хорошо вы спроектировали свои объекты и модели данных, насколько хорошо вы понимали свою среду ORM и насколько вы готовы к "коррупции""Ваша объектная модель.
Первый шаг настройки производительности любого приложения - всегда измерять дважды и сокращать один раз.Вы не можете просто перебрать список возможных решений и попробовать каждое из них, не зная, как они работают и в каких обстоятельствах они полезны;хорошо, вы могли бы сделать это, если ваш бизнес готов тратить на это время, но это часто не так.
Для начала вам нужно понять, почему собственные запросы предоставляют или появляются *, чтобы обеспечить лучшую производительность.Возможно, это во многом связано с тем, что вы просто вставляете данные, и для среды ORM было бы лучше просто выполнить оператор INSERT, а не создавать его из HQL или абстрактной нотации запросов, используемой под капотом.;только профилировщик покажет разницу.
Если вышеприведенное верно, то вы могли бы пересмотреть, должны ли ваши таблицы аудита управляться средой ORM.Если ваше приложение отвечает только за запись в эти таблицы, а не за чтение из них (и вполне возможно, что другое приложение отвечает за чтение записей), то я подозреваю, что отсутствие управления этими таблицами в ORM обеспечит лучшую производительность, особенноесли вы используете простой JDBC для выдачи оператора INSERT.Причина довольно проста - если ваша структура ORM управляет сущностью, то она также отвечает за управление контекстом постоянства (который теперь включает в себя класс и связанную таблицу);отсутствие управления ORM для объекта возможно приведет к сценарию, в котором контекст постоянства вообще не нужно обновлять для записей аудита.
Существует здоровая возможность других мер настройки производительности, которые выможет предпринять, но, как я уже говорил ранее, это потребует от вас понимания отчета профилировщика и оценки того, какие возможные варианты будут лучше в вашем приложении.
* Боюсь, что если вы не опубликуете тесты и то, как вы их провели, я буду скептически относиться к претензиям.