Что предпочтительнее для сопоставления значений: повторное использование функций сопоставления ИЛИ построение справочных таблиц для выполнения поиска?

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

Я в команде, которая любит использовать функции сопоставления для ввода и генерации некоторого вывода, обычно взаимно однозначным образом. Например, вот некоторый модифицированный код SAS, который показывает, что обычно делает моя команда:

 proc fcmp;
    function mapFunction($ input);
        output = .;
        if input= "Day zero" then output= 0;
            else if input = "Day one" then output = 1;
            else if input = "Day two" then output = 2;
        return(output);
    endsub;
run;
  

Затем команда будет использовать mapFunction в нескольких других программах, когда необходимо выполнить сопоставление.

Это противоречит моему инстинкту. Моим инстинктом было бы использовать функцию сопоставления один раз, чтобы сгенерировать набор пар ключ: значение или словарь или таблицу с двумя столбцами, а затем использовать операции поиска / индексирования / объединения / слияния для ссылки на таблицу.

Мне трудно объяснить, почему это мой инстинкт, но это так. Кажется, что лучше иметь справочную таблицу вместо повторного вызова пользовательской функции. Тем не менее, я не доверяю своим чувствам, и я хотел бы услышать от других, чтобы увидеть, могу ли я рационализировать один метод над другим.

Может ли кто-нибудь предоставить аргументы / контраргументы для поддержки того или иного метода?

Спасибо!

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

Позиция по умолчанию — использовать таблицу, как вы предлагаете. Его реальное преимущество в том, что а) вы можете запрашивать данные для проверки несуществующих значений на карте перед преобразованием; б) ответственность за подтверждение правильности сопоставления кода возвращается к бизнесу.

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

Я использовал функции для переноса использования таблицы сопоставления. Если вы не знаете, какой код будет проблематичным через месяц, это может быть полезно. Функция просто выбирает значение из таблицы сопоставления, как вы бы делали при объединении. Это будет выполняться медленнее, но если вы оптимизируете часы программиста, а не время выполнения, то это работает. В любом случае вы получаете видимость данных из карты кода, а также гибкость для расширения области видимости из функции. Когда область изменяется, просто обновите функцию.

Когда вы говорите «несколько других программ», звучит как красный флаг. Если вы храните данные в таблицах сопоставления, будет ли база данных, в которой они хранятся, видна этим программам? Это было бы важным соображением.

Каковы ваши критерии оценки?

Вы ищете:

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

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

В SAS я бы редко использовал FCMP, но форматы — это один из самых быстрых способов, и за ним действительно есть таблица, которую можно легко обновлять, так что это был бы мой выбор в SAS. Это немного медленнее, чем методы HASH и SET KEY, но его проще использовать и поддерживать, и в конечном итоге это экономит больше времени в долгосрочной перспективе. И я отдаю предпочтение человеческому времени перед компьютерным в 99% своих проектов.

Если вы выполняете поиск по lexjansen.com вы найдете много статей о различных способах выполнения поиска и сравнении времени их выполнения. https://www.lexjansen.com/phuse/2007/cs/CS06.pdf