Программирование Java - Где SQL-операторы должны быть сохранены? [закрытый]

Как писал rexem , состояния SQL - это код - их следует рассматривать как код, а не выносить во внешний вид (если у вас нет веской причины), а помещать их в код, который обрабатывает данные SQL из / в эти операторы. Сегодняшние фреймворки ORM / iBatis предлагают множество упрощений для повседневной разработки JDBC.

Некоторые ответы на ваш вопрос вы найдете в этом вопросе :) Проблема в том, как будут выглядеть ваши SQL-состояния. хранится в зависимости от вашего приложения. Что вам нужно? Высокая безопасность, простота написания кода или обслуживания, кроссплатформенность или привязка к поставщику? Следующий вопрос: нужен ли вам чистый SQL или ORM-фреймворк?

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

Простейшее решение (P),

Мои оказались в пакетах ресурсов. Я знаю, что это ненормально, но мне и всем "кроме меня" легче всего поддерживать его. Это просто и логично.

Мне действительно любопытно посмотреть, использует ли кто-нибудь мой подход также.

Из моего опыта, жесткое кодирование операторов sql в Объекты DAO - это то, что широко используется, хотя я думаю, что это должен быть наименее предпочтительный метод. Лучше всего хранить операторы sql в файле свойств. И получите инструкции в объекте DAO через интерфейс к файлам свойств, скажем java.util.Properties . Операторы sql могут перемежаться знаками '?' Для передачи параметров с помощью подхода Prepared Statement .

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

Я предлагаю использовать DAO с заводской компоновкой. Итак, примеры объектов, которые вам понадобятся:

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

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

Как и большинство из нас, я видел весь спектр, но нам нужно рассматривать SQL как первоклассный язык. Я даже видел, как SQL хранится в БД, который сначала опускается, а затем выполняется резервным копированием.

Самые успешные системы, которые я видел, используют хранимые процедуры, функции и представления.

Сохраненные процессы сохраняют текст SQL обратно в БД и позволяют относительно немедленное изменение с помощью РАЗВЕРТЫВАНИЯ и НАСТРОЙКИ (что требует большого количества правильного дизайна для его поддержки).

Все проекции должны быть через представления и простые выборки для по тем же причинам вся логика проекции должна содержаться в представлении.

Нам доводилось использовать сопоставитель SQL iBatis, который ближе к металлу, чем ORM, такие как Hibernate. В iBatis вы помещаете операторы SQL в файлы ресурсов (XML), которые должны находиться в пути к классам.

Ваш список подходов кажется довольно полным, если вы добавите ORM-опцию @ ocdecio. Я бы сказал, что использование ORM и использование сопоставителя SQL и файлов ресурсов - два лучших подхода. Я бы держался подальше от SQLJ, который не получил большого распространения и слишком тесно связывает вас с Java. Также держитесь подальше от хранимых процедур, поскольку они привязывают вас к конкретному поставщику базы данных (стандарты для хранимых процедур практически отсутствуют).

SQL внутри хранимых процедур оптимизирован системой баз данных и скомпилирован для обеспечения скорости - это ее естественный дом. SQL понимается системой баз данных, анализируется системой баз данных. Если можете, сохраните свой SQL в базе данных; оберните его в хранимые процедуры или функции или любые единицы логики, которые предоставляет система баз данных, и сделайте простые вызовы с помощью любого из инструментов, упомянутых вами или кем-либо еще.

Зачем хранить код SQL для системы баз данных вне базы данных ? Часто для скорости разработки. Зачем использовать ORM-отображение? - Некоторые говорят, что отображение ORM обеспечивает совместимость с различными системами баз данных; однако редко в реальном мире приложение когда-либо отходит от платформы базы данных после того, как оно было создано, особенно когда оно начинает использовать расширенные функции, такие как репликация, и в тех редких случаях, когда система базы данных заменяется, требуется некоторая работа. Я считаю, что одним из недостатков ORM он часто заменяет недостаток знаний SQL или недостаточное внимание к кодированию в базе данных. Кроме того, ORM никогда не будет соответствовать производительности собственной базы данных, даже если она приблизится.

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

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

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

Следует ли считать код SQL «кодом» или «метаданными»?

Код.

Должны ли хранимые процедуры использоваться только для оптимизации производительности или они являются законной абстракцией структуры базы данных ?

Хранимые процедуры допускают повторное использование, в том числе внутри других хранимых процедур. Это означает, что вы можете совершить одно посещение базы данных и заставить ее выполнять вспомогательные инструкции - в идеале наименьший объем трафика. ORM или sproc, время на проводе, идущем к db & back, - это то, что вы не можете окупить.

ORM не поддается оптимизации из-за своей абстракции. IME, ORM также означает отсутствие ссылочной целостности, что затрудняет создание отчетов по базе данных. То, что было сохранено в сложности, теперь увеличилось, чтобы можно было получать данные в работоспособном виде.

Является ли производительность ключевым фактором при принятии решения? А как насчет привязки к поставщику?

Нет, простота есть. Блокировка поставщика также происходит с базой данных - SQL относительно стандартизирован, но все еще существуют способы, специфичные для поставщика.

Используя ORM (например, спящий режим), у вас, надеюсь, не будет no операторов SQL, о которых нужно беспокоиться. Производительность обычно приемлемая, и вы также получаете независимость от поставщика.

Я не Не думаю, что кто-то даст вам подробное объяснение за / против, потому что это довольно большой вопрос. Вместо этого вот то, что я использовал в прошлом, и то, что я буду использовать в будущем.

Я использую SQL, жестко запрограммированный в DAL. Я думал, что это нормально, пока администраторы баз данных не захотели поиграть с SQL. Затем вам нужно откопать его, отформатировать и передать администраторам баз данных. Кто над этим посмеется и все заменит. Но без красивых вопросительных знаков или вопросительных знаков в неправильном порядке, и вам придется снова вставить это в код Java.

Мы также использовали ORM, и хотя это здорово для разработчиков, наши администраторы баз данных ненавидели его, так как для них нет SQL, над которым можно было бы смеяться. Мы также использовали странный ORM (заказной от стороннего поставщика), который имел привычку убивать базу данных. С тех пор я использовал JPA, и это было здорово, но получить что-либо сложное с его использованием после DBA - это непростая задача.

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

Забегая вперед, я хотел бы использовать хранимые процедуры с инструментами генерации кода для создания классов Java из пакетов Oracle.

Edit 2013-01-31 : Несколько лет спустя и администраторы баз данных, и теперь мы используем Hibernate, переходя на SQL (хранимые процессы в БД) только в случае крайней необходимости. Думаю, это лучшее решение. В 99% случаев базам данных не нужно беспокоиться о SQL, а в 1% случаев они делают это в том месте, где им уже комфортно.

Я не знаю, оптимально ли это, но по моему опыту они в конечном итоге жестко закодированы (то есть строковые литералы) на уровне DAO.

Единственный вопрос, на который вы задаете однозначный ответ, - это «Код SQL или метаданные?» Это определенно код, и поэтому он должен храниться в некотором виде контроля исходного кода и иметь систему для простого обновления до последней версии и отката , когда , а не в случае, если что-то пойдет не так.

I ' Мы видели три способа выполнения SQL в приложении, и у каждого из них есть свои плюсы и минусы. Нет лучшего способа, но лучше всего просто выбрать тот, который хорошо работает с вашим приложением, и придерживаться его.

• ORM - это сокращает количество SQL, которое вам нужно написать, и обрабатывает множество деталей за вас. Вам нужно будет сделать некоторый собственный SQL. Убедитесь, что у вас есть ORM, который изящно справляется с этим.
• Объекты доступа к данным - сохраняйте SQL в объектах, которые обращаются к данным. Это инкапсулирует вашу базу данных и делает так, чтобы остальной части вашего приложения не нужно было знать о базовой структуре БД, а только об интерфейсе к этим объектам.
• Хранимые процедуры - это сохраняет весь ваш SQL в вашей базе данных и позволяет администраторам баз данных легко узнать, что происходит. Все, что вам нужно сделать, это заставить ваш код вызывать сохраненные процедуры

Интересен страх перед привязкой к поставщику в мире Java.

Я надеюсь, что вы не заплатили 50000 долларов за ЦП за Oracle Enterprise, а затем использовали только наименьший общий знаменатель, чтобы в любую минуту переключиться на Mysql. Любой хороший администратор баз данных скажет вам, что между разными широко известными базами данных есть тонкие различия, особенно в отношении моделей блокировки и того, как они достигают согласованности.

Так что не принимайте решения о том, как реализовать только ваши SQL-вызовы. основан на принципе независимого от поставщика SQL - для этого есть реальная (деловая) причина.