между 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-коде. Разумеется, это вопрос вкуса, и его легко перемещать в хранимый файл позже, когда приложение созревает.

Answer 2

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

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

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

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

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

Answer 3

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

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

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