Малые территории и особые коды — это те места в справочнике, где привычная модель «одна страна — один короткий код» перестаёт работать. Население может быть совсем небольшим, но территория существует, у неё бывают собственные телефонные направления, собственная денежная единица и собственный порядок почтовых обозначений. Именно поэтому такие объекты так полезны для проверки: они дешёвы в подготовке и безжалостно вскрывают предположения, заложенные в модель данных.
Ниже разберём, какие регионы чаще всего ломают справочники, что делать с отсутствующими кодами, как обходиться со старыми названиями и почему «не поддерживаем» — не то же самое, что «ошибка в значении».
Какие регионы чаще всего ломают данные?
Первая группа — территории, которые существуют политически, но не считаются самостоятельными государствами. Их легко забыть при составлении перечня, потому что перечень обычно собирают по списку независимых стран.
Вторая группа — регионы со своим коротким кодом, но без остальных ожидаемых признаков: без собственного почтового обозначения, без отдельного формата адреса, иногда без собственной денежной единицы. Если модель требует, чтобы у записи с кодом были все поля, такие записи либо не добавляются вовсе, либо добавляются с выдуманными значениями.
Третья группа — объекты, которые в справочниках присутствуют только на нижнем уровне, как часть более крупной единицы. Их ищут как самостоятельные и не находят, после чего делают вывод, что данные неполны, хотя на самом деле искали не там.
Четвёртая группа — территории, изменившие статус. Старые записи о них остаются в исторических данных, и именно они чаще всего вызывают вопросы при разборе.
Общее свойство всех четырёх групп одно: каждая из них проверяет какое-то допущение, которое в модели данных никогда не проговаривалось вслух.
Не у каждого региона есть своя пара букв
Это ключевое наблюдение темы. Привычная пара символов есть у большинства широко известных стран, и из-за этого кажется, что она есть у всех. На практике часть регионов такой пары не имеет и представлена только внутри кодов нижнего уровня.
Отсюда несколько практических следствий.
- Поле кода нельзя объявлять обязательным для всех записей без исключений. Если объявить, придётся либо заполнять его произвольным значением, либо отказываться от части справочника.
- Список допустимых значений не обязан совпадать со списком кодов верхнего уровня. Он может быть шире, если включает устаревшие и зарезервированные обозначения, или уже, если часть регионов описывается иначе.
- Проверять нужно не только формат, но и применимость. Синтаксически правильное значение может не относиться к вашему справочнику вовсе.
- Не следует выводить применимость из длины или состава символов. Свойство «у этого региона есть свой код» — отдельный признак, который нужно хранить явно.
Коды, которые уже не используются для новых записей, но продолжают встречаться в исторических данных, — отдельная забота. Их нельзя отвергать как заведомо неверные: они описывают реальные прошлые записи. Правильная реакция — принять значение, распознать его как историческое и обработать по отдельному правилу, а не сообщать об ошибке формата.
Как обходиться со старыми и местными названиями?
Пользователи вводят названия так, как их знают. Это значит, что в поле может оказаться:
- местное название, отличающееся от привычного международного;
- прежнее название, действовавшее до изменения статуса или переименования;
- название, возникшее в результате объединения нескольких единиц;
- сокращение, принятое в отраслевых документах, но не в справочнике.
Требовать единственно верного написания — значит гарантированно терять часть корректных вводов. Но и принимать всё подряд нельзя: слишком щедрое сопоставление начнёт смешивать действительно разные объекты.
Разумный порядок такой. Сначала определяется каноническое значение записи, и уже к нему подбираются узнаваемые варианты написания. Если вариант узнан однозначно, значение принимается и заменяется каноническим. Если вариантов несколько или совпадение неточное, пользователю предлагается выбрать из небольшого списка. Если совпадений нет, ввод отклоняется как непонятный — но с честной формулировкой, а не с утверждением, что объект не существует.
Разбор сопоставления по названиям вынесен в отдельный материал про сопоставление названий стран и синонимы; здесь важно только то, что малые территории дают самую высокую долю таких вариантов.
Почему «не поддерживаем» и «ошибка» — разные вещи?
Это правило стоит проговорить отдельно, потому что нарушается оно постоянно.
«Мы не доставляем в этот регион» — решение о возможностях продукта. «Значение не соответствует нашим правилам» — сообщение о данных. «Мы не знаем такого региона» — сообщение о справочнике. Три разных состояния, три разных сообщения и три разных действия пользователя.
Если все три выражаются одной формулировкой об ошибке, пользователь начинает исправлять корректные данные. Он меняет написание, пробует соседний регион, иногда указывает заведомо неверный адрес, чтобы пройти дальше. В итоге в данных появляется мусор, а причина в том, что интерфейс не различил два разных события.
Отдельно стоит заметить, что отсутствие поддержки не должно влиять на проверку формата. Проверка формата отвечает на вопрос «выглядит ли значение правдоподобно», а не на вопрос «готовы ли мы туда отправлять». Смешение двух вопросов делает невозможным ни изменение правил доставки, ни изменение правил проверки: любая правка задевает вторую область.
Как не путать «неприменимо» и «неизвестно»?
Ещё одна пара состояний, которую почти всегда смешивают. «Неприменимо» означает, что для этого региона такого поля не существует в принципе: у него нет почтового обозначения, и это нормальное свойство, а не пробел. «Неизвестно» означает, что поле существует, но значение нам не сообщили.
Если хранить оба состояния как пустое значение, восстановить различие потом невозможно. Отчёт о полноте данных начнёт считать нормальные пропуски недостающими сведениями, и команда будет месяцами искать сведения, которых не существует. И наоборот: реальные пробелы растворятся среди ожидаемых пропусков и перестанут быть заметными.
Практический вывод прост: состояний должно быть три, а не два. Значение заполнено; значение неприменимо; значение неизвестно. Каждому состоянию — собственное представление, и правило перехода между ними.
Что важно разработчику
Первое: заведите для малых территорий небольшой фиксированный набор образцов. Не пытайтесь составить полную картотеку — она устареет быстрее, чем пригодится. Достаточно нескольких записей, каждая из которых проверяет своё свойство.
Второе: для каждой такой записи описывайте ожидаемое сочетание полей, а не только значения. Именно сочетание вскрывает допущения: где-то нет почтового обозначения, где-то больше уровней адреса, где-то название длиннее привычного.
Третье: не выводите признаки из кода. Наличие кода, применимость полей и поддержка доставки — три независимых признака, и каждый должен храниться явно.
Четвёртое: проверьте, что исторические обозначения не приводят к отказу. Прогоните через проверку значения, которые уже не используются для новых записей, и убедитесь, что они распознаются, а не считаются ошибкой.
Что делать дальше
Возьмите свой справочник и найдите в нём записи, у которых нет пары букв верхнего уровня. Скорее всего, их не так мало, как кажется, и именно они покажут, где модель данных требует невозможного.
Общая картина того, как устроены данные о странах и регионах, собрана в каталоге стран и регионов. Дальше полезно посмотреть на устройство кодов страны и административных единиц: там разобрано, чем отличаются уровни, и это прямо объясняет, почему часть регионов живёт только на нижнем уровне. И стоит вернуться к статье про выбор стран для тестовых данных: малые территории — типичный представитель третьей оси выбора, той, что отвечает за граничные случаи.
Примеры регионов, обозначений и сочетаний полей в этой статье вымышлены и приведены исключительно для объяснения устройства данных. Они не описывают принадлежность или статус какой-либо действительной территории и не являются справочной информацией.