отличается между cfstoredproc и cfquery

Question

Я нашел предыдущих программистов, использующих cfstoredproc в нашем существующем проекте о вставке записей в базу данных.

Просто пример, который он / она использовал так:

<cfstoredproc procedure="myProc" datasource="myDsn">
    <cfprocparam type="In" cfsqltype="CF_SQL_CHAR" value="ppshein" dbvarname="username">
    <cfprocparam type="In" cfsqltype="CF_SQL_CHAR" value="28 yrs" dbvarname="age">  
</cfstoredproc>

Я не могу убедитьпочему он / она использовал приведенный выше код вместо:

<cfquery datasource="myDsn">
    insert usertb
    (name, age)
    values
    (<cfqueryparam cfsqltype="CF_SQL_CHAR" value="ppshein">, <cfqueryparam cfsqltype="CF_SQL_CHAR" value="28 yrs">)
</cfquery>

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

Answer 1

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

Заметно ли это, зависит от вашей базы данных и вашего запроса. Использование CFQUERYPARAM внутри вашего CFQUERY (как в вашем примере) также ускоряет выполнение (на уровне драйвера db).

Если приложение ОЧЕНЬ чувствительно к производительности, я склонен сначала запускать свой код SQL в профилировщике, чтобы оптимизировать его, а затем помещать его в мой параметр CFQUERY, параметризованный тегами CFQUERYPARAM, а не использовать хранимый процесс. Таким образом, вся логика в коде CF. Это, конечно, дело вкуса, и легко перенести SQL в хранимый процесс позже, когда приложение станет зрелым.

Answer 2

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

Обновление : в этом сохраненном процессе может быть большепростой INSERT INTO.Там может быть какой-то поиск данных в другой таблице.Там может быть проверка.Там может быть условная логика.Может происходить несколько транзакций, например, журнал.Невозможность выполнить вставку может вернуть определенный код состояния, а не выдать ошибку.

Честно говоря, это просто вопрос стиля.Есть причины для и против того или иного пути, и я обнаружил, что обычно все сводится к тому, у кого есть более / более компетентные программисты: парни CF или парни из базы данных.

Answer 3

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

Итак, как правило: запросы, которые ...

1. большой и сложный или
2. звонили очень часто или
3. оба вышеперечисленных

... очень хорошие кандидаты для преобразования в хранимую процедуру.

Надеюсь, это поможет!