Как обрабатывать огромные строки SQL в исходном коде

Question

Я работаю над проектом, в котором в коде есть строки SQL длиной около 3000 строк.

Проект представляет собой проект Java, но этот вопрос, вероятно, может относиться к любому языку.

Во всяком случае, я впервые вижу что-то такое плохое. Кодовая база устарела, поэтому мы можем внезапно перейти на Hibernate или что-то в этом роде.

Как вы обрабатываете такие большие строки SQL?

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

Answer 1

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

Answer 2

Есть ли в SQL много строковых конкатенаций для переменных?

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

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

Для моего предложения это было бы так:

String query = "select ......."+
3000 lines.

К

ResourceBundle bundle = ResourceBundle.getBundle("queries");
String query = bundle.getString( "customerQuery" );

Ну, это идея.

Answer 3

Наверное, первый вопрос: что вы должны делать с этим? Если он не сломан, тихо закройте его и представьте, что вы его никогда не видели. В противном случае, рефакторинг как сумасшедший - надеюсь, где-то будет какое-то условие выхода, похожее на контракт.

Answer 4

Я нахожусь в том же месте, что и вы ... Мой план состоял в том, чтобы вытянуть SQL-файл в отдельные файлы.sql в рамках проекта и создать служебный метод для чтения файла, когда мне потребуется запрос.

string sql = "select asd,asdf,ads,asdf,asdf," 
           + "from asdfj asfj as fasdkfjl asf"
           + "..........................."
           + "where user = @user and ........";

Запрос сбрасывается в файл с именем useReportByUser.sql
и становится что-то вроде этого.

string sql = util.queries("usageReportByUser");

Убедитесь, что это сделано таким образом, что файлы не являются общедоступными.

Answer 5

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

Answer 6

Я вторая рекомендация iBatis. По крайней мере, вы можете извлечь SQL из Java-кода, который, скорее всего, использует StringBuffer и добавляет или String concat в XML, где его проще поддерживать.

Я сделал это для устаревшего веб-приложения, включил отладку и запустил модульные тесты для DAO, и просто скопировал сгенерированный sql для каждого оператора в iBatis xml. Работал довольно гладко.

Answer 7

Некоторое время назад я написал инструментарий и использовал его в нескольких проектах. Он позволяет вам размещать запросы в основном в текстовых файлах и генерировать привязки и документацию для них.

Извлеките , в этом примере , а в примере используется (это в значительной степени просто подготовленный оператор, скомпилированный в класс Java с ранними привязками / привязками запросов типов).

Он также генерирует несколько хороших javadocs, но в данный момент у меня их нет в сети.

Answer 8

Используйте рамки iBatis

Answer 9

Что я делаю в PHP это:

$query = "SELECT * FROM table WHERE ";
$query .= "condition < 5 AND ";
$query .= "condition2 > 10 AND ";

и затем, как только вы закончите наложение на $query:

mysql_query($query);

Answer 10

Мне удалось преобразовать большие динамические запросы в запросы linq. (1K строк +). Это очень хорошо работает для отчетов о сценариях, где у вас много динамической фильтрации и динамической группировки по относительно небольшому количеству таблиц. Создайте edmx для этих таблиц, и вы сможете написать отличные строго типизированные составные запросы.

Я обнаружил, что производительность действительно улучшилась, и в результате sql стал намного проще. Я уверен, что вы получите такой же пробег с Hibernate - кроме возможности использовать linq ofcourse. Но, вообще говоря, если сгенерированный sql должен быть высоко динамичным, то он не является хорошим кандидатом для хранимого процесса. Написание динамического SQL внутри хранимой процедуры является худшим из обоих миров. Фреймворки генерации SQL были бы моим предпочтительным способом пойти сюда. Если вы копаете Hibernate, я думаю, это было бы хорошим решением.

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