Циклы ЦП машины БД и циклы ЦП машины среднего уровня

Question

У меня есть запрос SELECT с большим количеством условий IF, который я могу выполнить либо в самом запросе (принимает ЦП компьютера БД), либо я могу поместить его в свой код Java (принимает ЦП сервера).

Есть ли здесь какой-либо предпочтительный подход (поместить условия в БД Vs на средний уровень)?

ОБНОВЛЕНИЕ : Мой запрос представляет собой объединение более 2 таблиц, и я использую левое соединение для объединения, и есть некоторые строки, которые будут иметь соответствующую строку во 2-й таблице, а некоторые нет. Мне нужно иметь некоторое значение по умолчанию для этих столбцов, когда у меня нет соответствующей строки во 2-й таблице.

SElECT CASE WHEN t2.col1 is null
    then 'default' else t2.col1
    END
FROM table1 t1
LEFT JOIN table2 t2 ON t1.id = t2.id

Answer 1

Если это действительно то, что БД не может делать быстрее сервера приложений, и , что фактически снижает нагрузку на сервер БД при перемещении на сервер приложений, то я бы переместил это на сервер приложений.

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

Однако второе условие, приведенное выше, должно быть тщательно проверено: многие вещи не уменьшат (или даже не увеличат) нагрузку на БД при удалении от БД.

Обновление: Для того, что вам нужно, я сомневаюсь, выполнено ли первое условие - проверяли ли вы его? Простой CASE совершенно незначителен, если только условие или ветви не содержат очень дорогих вычислений.

Answer 2

Да, хотя я бы предложил другой подход, который не увеличивает нагрузку на сервер приложений и минимальную нагрузку на СУБД.Немного сложно ответить на вопрос, поскольку вы не предоставили конкретный пример, но я приведу пример.

Мое предпочтительное решение - полностью избавиться от условий if, если вы можете.Как минимум, вы можете перенастроить свою схему базы данных, чтобы переместить стоимость вычисления от select (что часто происходит) в insert/update (что происходит реже).

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

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

Вместо чудовищного оператора select, чтобы (возможно) разделить имя и подсчитать символы всделайте это как триггер вставки / обновления, когда данные поступают в таблицу - это единственный раз, когда значение может измениться в конце концов.

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

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

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

---

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

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