Nano Hash - криптовалюты, майнинг, программирование

Есть ли недостаток в том, чтобы ставить N перед строками в сценариях? Считается ли это лучшей практикой?

Допустим, у меня есть таблица с полем varchar. Если я сделаю вставку следующим образом:

INSERT MyTable 
 SELECT N'the string goes here'

Есть ли принципиальная разница между этим и:

INSERT MyTable 
 SELECT 'the string goes here'

Насколько я понимаю, у вас возникнут проблемы только в том случае, если строка содержит символ Unicode, а целевой столбец не соответствует Unicode. Кроме этого, SQL отлично справляется с этим и преобразует строку с N'' в поле varchar (в основном игнорирует N).

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

sql sql-server unicode
26.04.2010

Ответы:


1

Короткий ответ: подходит для скриптов, плохо для производственного кода.

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

Если кто-то не знает, куда идет вставка, или не знает, откуда берется исходный текст (скажем, это утилита вставки данных общего назначения, которая генерирует операторы вставки для неизвестной цели, скажем, при экспорте данных), N 'foo' может быть более защитным стилем кодирования.

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

Однако, если рассматриваемый код предназначен для повторного использования в среде, где вы заботитесь о качестве кода, вам не следует использовать N'the string', потому что вы добавляете преобразование там, где оно не требуется.

26.04.2010
  • Ах, защита, мне нравится этот термин здесь. +1 26.04.2010
  • Я думаю, что это, в сочетании с одним выше, является ответом. Думаю, я отредактирую это и назову это ответом. 27.04.2010
  • @jcollum: Дело не только в производительности конверсии. Вы указываете неправильную семантику будущим сопровождающим. Это немного похоже на запись предикатов как WHERE SomeCol = '1', как если бы это был столбец varchar, хотя на самом деле это столбец int. Это может работать, но это не делает его менее неправильным, и это может привести к незначительным ошибкам, связанным с сопоставлением, в будущем, когда сценарий будет изменен. Сгенерированный код явно не соответствует таким высоким стандартам качества, как написанный код; то же самое, как правило, верно для любого генератора кода, попробуйте взглянуть на конструктор кода программной части Windows Form. 28.04.2010
  • @aaron: в сценариях есть множество мест, где даты и время передаются в виде строк «2010-04-28 00:31». Я не понимаю, что вы имеете в виду об ошибках сопоставления. т.е. Я не понимаю, как запрос sql на преобразование и nvarchar в varchar (перед вставкой данных для столбца) может привести к ошибкам сопоставления. 30.04.2010
  • @aaron: моя редакция этого ответа также касалась того, чтобы не делать этого в производственном коде, что я считаю уместным. Я не вижу никаких недостатков в том, чтобы делать это в сценариях. Пожалуйста, проиллюстрируйте, если вы видите проблему, которую я не вижу. 30.04.2010
  • @jcollum: Моя проблема была с вашим последним предложением, потому что вы добавляете преобразование там, где оно не требуется. Подразумевается, что это единственная причина, но более важная причина заключается в том, что она просто вводит в заблуждение. Генераторы кода не заботятся об этом, потому что сгенерированный машиной код не предназначен для человеческого восприятия. 30.04.2010
  • @aaron: я думаю, вы читаете единственную причину, когда об этом не говорится. Это всего лишь первая причина, которую я выбрал, и наиболее поддающаяся количественной оценке. 30.04.2010

    • 2

    Вы должны добавлять к строкам префикс N, если они предназначены для столбца или параметра nvarchar(...). Если они предназначены для столбца или параметра varchar(...), пропустите его, иначе вы получите ненужное преобразование.

    Определенно не рекомендуется вставлять N перед каждой строкой, независимо от того, для чего она предназначена.

    26.04.2010
  • Но если вы поставите N впереди, вам действительно не нужно знать, каков тип данных целевого столбца. Беспокойство о дополнительной конверсии похоже на микрооптимизацию. 26.04.2010
  • @jcollum: факт остается фактом: лучше всего использовать то, что на самом деле правильно. Кто-то может посмотреть на ваш запрос и сделать ошибочный вывод, что столбец поддерживает символы Unicode, хотя на самом деле это не так. 26.04.2010
  • Тогда мне интересно, почему так много инструментов ставят N перед строками, независимо от типа назначения. 26.04.2010
  • @jcollum: Это очень хороший вопрос. Может быть, это просто лень - проще использовать один и тот же код для всех типов символов, чем писать специальный код на основе настроек Unicode. 26.04.2010

    • 3

    Из INSERT (Transact-SQL)

    При обращении к символьным типам данных Юникода nchar, nvarchar и ntext перед выражением должна стоять заглавная буква «N».

    Также прочитайте Почему есть ли в некоторых строках SQL префикс 'N'?

    А также

    Программирование на стороне сервера с использованием Unicode

    Строковые константы Unicode, которые появляются в коде, выполняемом на сервере, например, в хранимых процедурах и триггерах, должны начинаться с заглавной буквы N. Это верно, даже если столбец, на который делается ссылка, уже определен как Unicode. Без префикса N строка преобразуется в кодовую страницу базы данных по умолчанию. Это может не распознавать определенные символы.

    26.04.2010
  • Не отвечает на вопрос. Я не спрашивал, почему он там. Мне было интересно, есть ли обратная сторона или лучше всего иметь ее там независимо. 26.04.2010
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..