Является ли хорошей практикой урезание пробелов (начальное и конечное) при выборе / вставке / обновлении данных поля таблицы? - PullRequest
2 голосов
/ 18 июля 2009

Предполагая, что пробелы не важны в данных поля, рекомендуется ли обрезать пробелы при вставке, обновлении или выборе данных из таблицы?

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

Что ты думаешь?

Ответы [ 7 ]

3 голосов
/ 18 июля 2009

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

3 голосов
/ 18 июля 2009

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

3 голосов
/ 18 июля 2009

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

Это дает некоторые преимущества. Меньше места, требуемого в строке, означает, что потенциально потенциально большее количество строк может существовать на странице данных, что приводит к более быстрому извлечению данных (меньше для извлечения). Кроме того, вы не постоянно обрезаете данные на SELECT. (Использует принцип СУХОЙ [не повторяйся] здесь)

1 голос
/ 18 июля 2009

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

0 голосов
/ 13 июня 2018

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

Либо обрежьте их во время вставки / обновления, либо добавьте условие проверки в вашу таблицу следующим образом:

ALTER TABLE tblData
WITH CHECK ADD  CONSTRAINT CK_Spaces_tblData 
CHECK 
(
    datalength(USERID)>(0) 
    AND datalength(ltrim(rtrim(USERID)))=datalength(USERID) 
)

В этом случае пользователи получают ошибку при попытке вставить или обновить.

Преимущество в том, что пользователи знают об ошибке. Очень часто у них уже есть конечные пробелы в некоторых листах Excel, а затем они копируют и вставляют. Так что им полезно знать об этом, чтобы они могли устранить ошибку и в своих таблицах Excel.

0 голосов
/ 18 июля 2009

Конечные пробелы особенно проблематичны, особенно в отношении поведения ANSI_NULLS.

Например, colname = '1' может возвращать true, когда colname, например '1', возвращает false

Таким образом, заданные пробелы в столбцах varchar неоднозначны, усечение, скорее всего, предпочтительнее, особенно потому, что в таких данных нет реальной информации, и это создает неоднозначность в поведении SQL Server.

Например, посмотрите обсуждение этого вопроса:

Почему оператор выбора SqlServer выбирает строки, которые совпадают, и строки, которые совпадают и имеют завершающие пробелы

0 голосов
/ 18 июля 2009

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

...