Как вы показываете чувствительность к регистру для пользователей?

Question

Хорошо, я понял. Данные в PostgreSQL чувствительны к регистру. И я знаю, что могу использовать LOWER (), чтобы сделать мои запросы без учета регистра. Я знаю, что в будущей версии PostgreSQL может быть даже тип " citext ". Мой вопрос, сегодня, как вы справляетесь с этим при разработке пользовательских интерфейсов? Я имею в виду конкретно ограничения уникальности.

Допустим, данные моего приложения более или менее похожи на файловую систему (подумайте, Google Docs, за исключением того, что Google Docs фактически допускает дублирование имен :-P). Как я могу облегчить нашим пользователям понимание того факта, что они могут иметь повторяющиеся имена, если дело обстоит иначе? Я думаю, что большинству людей это просто покажется странным .

Давайте упреждаем некоторые вопросы с пути:

1. Я родом из Windows, поэтому я так «чувствую» к регистру символов. Сейчас я в основном использую Mac OS X, которая (вы знали?) также не учитывает регистр . Большинство наших пользователей вписываются в эти же два ведра.

2. Я новичок в PostgreSQL. Большая часть моего опыта связана с MySQL, но я также использовал Oracle, который чувствителен к регистру, как PostgreSQL. Тогда я тоже много думал об этой проблеме, но в итоге оставил все как есть и позволил нашим пользователям просто разобраться.

3. Меня интересуют как технические решения (т. Е. Решение этой проблемы просто исчезло), так и решения по разработке пользовательского интерфейса (т. Е. Помощь пользователю в использовании системы).

Резюме:

• Как вы справляетесь с нечувствительностью к регистру при разработке пользовательских интерфейсов?
• Как я могу облегчить нашим пользователям понимание того факта, что они могут иметь повторяющиеся имена, если дело обстоит иначе?

РЕДАКТИРОВАТЬ : Я ценю все отзывы до сих пор. Однако, если ответ «не разрешать повторяющиеся имена, если они различаются в зависимости от регистра», тогда как мне реализовать это в PostgreSQL? Одним из решений, которое я рассмотрел, является сохранение отдельного столбца, который всегда является версией данных LOWER (), и наложение уникального ограничения на этот столбец.

Answer 1

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

РЕДАКТИРОВАТЬ Что касается уникального ограничения :

CREATE UNIQUE INDEX
    example_unique_idx
ON
    example_table ((LOWER(case_insensitive_field)));

Answer 2

Возможно, вы не знаете об этом, но вы можете создавать уникальные индексы над функцией. И даже сделать их частичными индексами.

Например:

create unique index some_name on users (lower(username));

сделает имя пользователя уникальным независимо от регистра.

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

create unique index some_name on users (lower(username)) where is_active = true;

Также обратите внимание, что для поиска без учета регистра вы не должны использовать ILIKE. Проблема в том, что ILIKE не может (по некоторым причинам, которые я не совсем понимаю) использовать индексы.

Итак, пока можно использовать функциональный индекс для ускорения запросов:

select * from users where lower(username) = '...'

или

select * from users where lower(username) like '...'

(хотя бы для некоторых значений "...")

индекс не будет использоваться (насколько я знаю) в:

select * from users where username ilike '...'

Answer 3

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

Answer 4

• Как вы справляетесь с нечувствительностью к регистру при разработке пользовательских интерфейсов?

Вы не позволяете пользователям создавать объекты с одинаковыми именами при сравнении без учета регистра, если только у вас нет особой целевой аудитории, которая уже «получает». Обычные пользователи компьютеров, Эмили Исполнительная, не поймут, почему у нее есть два файла для «Квартального отчета» и «Квартального отчета» - это только ухудшит удобство использования вашего продукта, если только сценарии приложения или использования не требуют учета регистра. 1005 *

Другими словами, если это не является обязательным требованием, допускается регистронезависимость.

• Как я могу облегчить нашим пользователям понимание того факта, что они могут иметь повторяющиеся имена, если дело обстоит иначе?

Если вы должны сделать это, используйте шрифт, который делает очевидным, что имена разные. Дайте пользователю опцию, которая включает и выключает предупреждения: «У этого файла есть имя, похожее на этот другой файл, вы уверены, что хотите сохранить его под этим именем?» с автоматическим включением при запуске (отказаться от участия в общих предупреждениях)

-Adam

Answer 5

Чувствительность к регистру заставляет вашего пользователя решать проблемы в компьютерном мире.

Не подвергайте чувствительность к регистру!

Вы только что сказали мне, что и Windows, и Mac нечувствительны к регистру, они должны уменьшить путаницу для пользователя.

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