Подтвердить что ты не робот

Где я должен помещать файлы SQL в проект Java?

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

Я уверен, что хочу, чтобы каждый оператор имел свой собственный текстовый файл, управляемый с помощью элемента управления исходным кодом. Поскольку Java не поддерживает многострочные строки, я не могу легко поместить SQL в мои файлы .java, и я не думаю, что я хотел бы в любом случае. Во время сборки я могу поместить эти текстовые файлы в JAR и получить содержимое ClassLoader.getResourceAsStream().

Итак, моя проблема заключается в том, в каких каталогах я должен поместить эти файлы и что я должен их назвать. В идеале я хотел бы, чтобы люди рассказывали из файла .sql, который использует его класс Java. То, что я определенно не хочу, - это один каталог с множеством файлов, называемых такими вещами, как report1.sql и report3.sql и т.д.

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

Поэтому мне было бы интересно узнать, что вы делаете с вашими SQL файлами.

Мы используем Netbeans 6.5 в случае, если это повлияет на ваши ответы.

(Этот вопрос похож, но, к сожалению, ответы очень специфичны для С#, что хорошо для этого вопроса, но плохо для меня.)

4b9b3361

Ответ 1

В настройке Java/Maven мы используем иерархию проектов:

project/src/main/java/Package/Class.java
project/src/test/java/Package/ClassTest.java
project/src/main/resources/Package/resource.properties
project/src/test/resources/Package/test_resource.properties

И чтобы ответить на ваш вопрос: я бы поместил SQL файлы вместе с ресурсами в src/main/resources.

Вы можете посмотреть этот поток.

Ответ 2

У меня возникнет соблазн поставить SQL-запросы в выделенную папку SQL в src. Это отделяет Java-код от SQL:

+ src
  + java 
  + sql
     - Package/Class.sql
+ test

В качестве альтернативы вы можете поместить их в простые файлы свойств, используя указанную выше структуру:

getUserByName = select * from users where name=?

getUserByEmail = select * from users where email=?

getUserByLongQuery = select * from users where email=? \
   and something = ? \
   where something_else = ?

Кроме того, я думаю, стоит упомянуть, что вы можете поместить многострочные строки в класс Java, если вы предпочитаете использовать этот маршрут:

class MyClass {
    MY_QUERY = "select * from users where email = ? " + 
               "and something_else = ?";
}

Ответ 3

Я полностью согласен с boutta. Maven устанавливает хороший стандарт для управления папками src. Рассматривали ли вы хранение своего SQL в XML? Сохранение запросов в одном файле может упростить управление SQL. Моя первая интуиция - это нечто простое:

<?xml version="1.0" encoding="UTF-8"?>
<queries>
    <query id="getUserByName">
        select * from users where name=?
    </query>
    <query id="getUserByEmail">
        select * from users where email=?
    </query>
</queries>

Чтобы проанализировать файл, используйте xpath или даже SAX для создания карты запросов, заданных идентификатором для быстрого поиска запросов.

Ответ 4

Чтобы быть согласованным с http://maven.apache.org/pom.html#Resources, это место может быть одним из:

  • src/main/sql
  • src/main/upgrade - для сценариев обновления между версиями
  • src/main/db, src/main/schema, src/main/ddl - для текущей схемы DB проекта, для первоначального развертывания проекта
  • и т.д., просто поместите в каталог src/main/NAME

Другие вещи, которые следует учитывать:

Обратите внимание, что среда IDE не поддерживает каталоги прослушивания, отличные от src/main/java и src/main/resources в средстве просмотра проектов, для этого используется просмотрщик файлов.

Ответ 5

Это небольшой рифф на начальном вопросе, но, возможно, чем сложнее SQL, тем больше он принадлежит в базе данных (или на уровне услуг), а не в вашем Java-коде.

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