Нормализация строк с помощью String.ToUpperInvariant ()

В настоящее время я храню нормализованные версии строк в своей базе данных SQL Server в нижнем регистре. Например, в моей таблице «Пользователи» есть поля UserName и LoweredUserName. В зависимости от контекста я использую либо функцию T-SQL LOWER (), либо метод C # String.ToLower (), чтобы сгенерировать версию имени пользователя в нижнем регистре для заполнения поля LoweredUserName. В соответствии с рекомендациями Microsoft и правило анализа кода Visual Studio CA1308, я должен использовать C # String.ToUpperInvariant () вместо ToLower (). Согласно Microsoft, это проблема как производительности, так и глобализации: преобразование в верхний регистр безопасно, в то время как преобразование в нижний регистр может вызвать потерю информации (например, турецкая проблема" я ").

Если я перейду к использованию ToUpperInvariant для нормализации строк, мне также придется изменить схему моей базы данных, поскольку моя схема основана на Платформа членства Microsoft ASP.NET (см. этот связанный вопрос), который нормализует строки до нижнего регистра.

Разве Microsoft не противоречит сама себе, говоря нам использовать нормализацию верхнего регистра в C #, в то время как ее собственный код в таблицах и процедурах членства использует нормализацию нижнего регистра? Должен ли я переключить все на нормализацию верхнего регистра или просто продолжать использовать нормализацию нижнего регистра?


c# sql-server asp.net code-analysis asp.net-membership
person Kevin Albrecht    schedule 21.04.2009    source источник

Ответы (3)


arrow_upward
3
arrow_downward

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

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

Помните:

Преждевременная оптимизация - это корень всех зол (или, по крайней мере, большей их части) в программировании. - Дональд Кнут

person Andrew Hare    schedule 21.04.2009
comment
Это не только проблема производительности, но и проблема глобализации. По заявлению Microsoft, преобразование в верхний регистр безопасно, в то время как преобразование в нижний регистр может привести к потере информации (например, в турецком языке проблема с буквой I). - person Kevin Albrecht; 21.04.2009
comment
@Kevin, турецкая / азербайджанская проблема без точки I остается особым случаем, какой бы подход ни использовался (они прописные i - İ и ı - I), хотя нижний регистр для SS неоднозначен (должен быть ss или ß), но это тоже несовершенно (некоторые орфографии по-прежнему прописные от ß до SZ). Но все же лучше. Еще лучше использовать правила сворачивания регистра Unicode с тюркским переключателем для i и ı, но это все равно не будет идеально, это может быть только для каждой локали :( - person Jon Hanna; 28.10.2010

arrow_upward
8
arrow_downward

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

person JoshBerke    schedule 21.04.2009
comment
Мне нравится такой подход. Если начинать с нуля, следование рекомендованному стандарту всегда является лучшей практикой в ​​свете отсутствия другой мотивации поступать иначе, но при работе над существующим обслуживанием часто глупо просто переключаться, потому что так сказано. Вам нужны неопровержимые доказательства того, что это изменение принесет пользу вашему проекту, прежде чем приступать к такому капитальному ремонту - может быть, когда вы начнете обрабатывать турецкий язык и столкнетесь с проблемой? - person Jeff Yates; 21.04.2009
comment
Я полностью согласен, Джефф, есть некоторые рекомендации, которым вы должны следовать, и я бы сказал, что, возможно, стоит обновить существующий код, чтобы следовать им (например, убедитесь, что вы удалили свой считыватель данных). Однако это не одно из этих правил и даже близко не к нему. - person JoshBerke; 21.04.2009

arrow_upward
-2
arrow_downward

Продолжайте использовать нормализацию нижнего регистра. Изменяйте в соответствии со стандартами Microsoft только в случае возникновения серьезной проблемы.

Это прискорбно, но того стоит. К сожалению, «стандарты» Microsoft, как правило, плохо рассматриваются и несколько менее согласованы; опыт их использования показал, что, если нет веской причины, лучше просто придерживаться того, что работает, пока оно работает. Обратите внимание, что это, как правило, НЕ относится к технологиям сторонних разработчиков; но произвольность «стандартов» Microsoft заставляет их избегать.

Изменить: я должен уточнить здесь; Мое мнение о Microsoft очень низкое из-за длительного опыта работы с их стандартами. Как было указано в комментариях, у меня нет конкретных ссылок на «всех, кроме Microsoft»; это просто исходит из моего личного опыта. Ваш пробег может сильно различаться. Этот ответ следует считать действительно просто моим мнением. Извините, что не уточнил это раньше.

person Paul Sonier    schedule 21.04.2009
comment
Я думаю, что вам нужно процитировать некоторые источники, прежде чем заявлять обо всех, кроме Microsoft, когда дело касается стандартов. В последние годы Microsoft, похоже, уделяет большое внимание исследованию мотивов, лежащих в основе их стандартов, и, хотя их реализация веб-стандартов в IE была далека от идеала, стандарты, которые они определяют для нас для работы с их продуктами, часто превосходны. Пожалуйста, подкрепите свои утверждения, чтобы они не были истолкованы как горькое мнение. - person Jeff Yates; 21.04.2009
comment
Я согласен, Джефф, их стандарты очень последовательны, их принятие стандартов меньше, но это ожидается, код, который был написан до принятия стандарта, не будет обновлен только для того, чтобы привести его в соответствие. Представьте, если бы они изменили все свои пространства имен, чтобы отразить их новый подход к выбору пространств имен и всех разработчиков, которые кричат ​​о кровавом убийстве. - person JoshBerke; 21.04.2009
comment
Вы оба хороши; Моя позиция на самом деле исходит из довольно горького мнения и большого количества дерьмового опыта работы с Microsoft. Я обновлюсь, чтобы отразить это. - person Paul Sonier; 21.04.2009