Каковы детали использования CF_SQL_NVARCHAR в ColdFusion 10?
Документация ColdFusion 10 по обновлению базы данных содержит раздел об улучшениях, связанных с базой данных в ColdFusion 10 . На этой странице упоминается, что теперь есть поддержка CF_SQL_NVARCHAR , но нет подробностей о них. Кроме того, документация cfqueryparam не была обновлена, чтобы включить их существование.
Документация ColdFusion 9 для cfqueryparam упоминает, что CF_SQL_VARCHAR сопоставляется с varchar в MSSQL. Это верно, если только в настройках источника данных ColdFusion Administrator не включен параметр String Format . В этом случае CF_SQL_VARCHAR сопоставляется с nvarchar . Эта плохо документированная функция – это взлом, который может вызвать проблемы с производительностью в ColdFusion.
Поэтому здорово, что они внедрили CF_SQL_NVARCHAR , но было бы хорошо понять, как это работает. Это просто псевдоним для CF_SQL_VARCHAR что делает его бессмысленным? Всегда ли он отправляет строки как nvarchar ? Если да, то CF_SQL_VARCHAR всегда отправляется в varchar ?
Надеюсь, что для обратной совместимости он реализован как таковой:
Если параметр String Format включен CF_SQL_VARCHAR и CF_SQL_NVARCHAR оба отображаются в nvarchar .
Если String Format отключен, CF_SQL_VARCHAR сопоставляет карты varchar и CF_SQL_NVARCHAR с nvarchar .
Это означало бы, что любые сайты pre-CF10 могут перейти на CF10 и работать с такими же соображениями производительности до CF10.
Новые сайты или сайты, которые переписывают все запросы в соответствие с CF_SQL_VARCHAR и CF_SQL_NVARCHAR с дизайном базы данных, не получат штраф за производительность, который неизбежен до CF10.
Может ли кто-нибудь подтвердить, если это так; еще лучше, если с чем-то официальным?
Пока вы ждёте что-то более официальное, я заберу свои 0,02 доллара …
Я сделал некоторые копания и основываясь на своих наблюдениях (с источником данных MS SQL), я считаю, что:
-
CF_SQL_NVARCHAR– это не просто псевдоним дляCF_SQL_VARCHAR. Он сопоставляется с новым типом NVARCHAR jdbc , который позволяет обрабатывать значения Unicode на более узком уровне. -
Значения
CF_SQL_NVARCHARвсегда рассматриваются какnvarchar - Обработка
CF_SQL_VARCHARзависит от параметраString Format, как и в предыдущих версиях.
CF_SQL_NVARCHAR Тест / результаты:
Если вы включите ведение журнала данных, вы увидите, что драйвер вызывает специальный метод CF_SQL_NVARCHAR всякий раз, когда используется CF_SQL_NVARCHAR . Таким образом, в конечном итоге значение отправляется в базу данных как nvarchar . (Вы можете подтвердить это с помощью SQL Profiler)
// Query SELECT ID FROM Test WHERE NVarcharColumn = // Log spy(...)>> PreparedStatement[9].setNString(int parameterIndex, String value) // Profiler exec sp_prepexec @p1 output,N'@P1 nvarchar(4000)',N'SELECT ID FROM Test WHERE NVarcharColumn = @P1 ',N'Стоял он, дум великих полн'
CF_SQL_VARCHAR Тест / результаты:
В случае CF_SQL_VARCHAR он технически помечен как varchar . Тем не менее, параметр String Format конечном итоге контролирует, как он обрабатывается базой данных. Когда настройка включена, она обрабатывается как nvarchar . Когда он отключен, он рассматривается как varchar . Опять же, вы можете проверить это с помощью SQL Profiler.
Итог, все, что я видел до сих пор, говорит, что вы правы на цели реализации.
// Query SELECT ID FROM Test WHERE PlainVarcharColumn = // Log spy(..)>> PreparedStatement[8].setObject(int parameterIndex, Object x, int targetSqlType) spy(..)>> parameterIndex = 1 spy(..)>> x = ????? ??, ??? ??????? ???? spy(..)>> targetSqlType = 12 (ie CF_SQL_VARCHAR) // Profiler (Setting ENABLED) exec sp_prepexec @p1 output,N'@P1 nvarchar(4000)',N'SELECT ID FROM Test WHERE PlainVarcharColumn = @P1 ',N'Стоял он, дум великих полн' // Profiler (Setting DIS-abled) exec sp_prepexec @p1 output,N'@P1 varchar(8000)',N'SELECT ID FROM Test WHERE PlainVarcharColumn = @P1 ','????? ??, ??? ??????? ????'