В наших последних постах вы видели, что большинство аналитиков наших клиентов испытывают трудности с написанием кода снова и снова. Но если честно, вы, вероятно, еще не верите нам, не так ли?
И даже если вы нам поверили, вы, вероятно, спросите о некоторых примерах или о том, как вы можете начать решать эту задачу.
Итак, сегодня мы собираемся показать вам пять способов переписывания кода и причину, по которой мы считаем, что вам следует подумать об использовании каталога активной аналитики, чтобы помочь вам и вашей команде стать еще более продуктивными.
1. Стандартизируйте противоречивые бизнес-правила (которые скрываются в предложениях WHERE и операторах CASE для ваших аналитиков).
ВЫ: Эй, босс, вы знаете, как мы сообщали о более низких показателях продаж на одного клиента, чем в отчетах отдела маркетинга?
БОСС: Да, это сводит команду лидеров с ума. Какой номер правильный?
ВЫ (нервно): Их… оказывается, 6 недель назад в систему POS был добавлен новый код транзакции, и мы никогда не обновляли нашу логику. Таким образом, мы пропустили эти продажи в наших подсчетах.
БОСС (голова взрывается): И все? Одно маленькое значение кода??!?!?
Они кажутся такими незначительными вещами, но в каждой компании, с которой мы работаем, логика в SQL-операторах CASE и предложениях WHERE, как ни странно, заключается в том, что ГДЕ вводится так много несоответствий, что усложняет поддержание «единой версии истины». ”
Представьте, что каждый раз при изменении вашего веб-приложения и мобильного приложения вы вручную изменяете оператор CASE длиной в сотни строк. Нет, спасибо! Но с активным каталогом аналитики Aginity вы можете вместо этого хранить эти сложные правила в виде фрагментов, благодаря чему оператор SQL из 200+ строк выглядит намного чище и красивее, например:
ВЫБРАТЬ
Идентификатор_события
,код_события
,Код_типа_страницы
,Event_timestamp
,ID посетителя
,App_ID
,Тип_браузера
,@{Тип делового мероприятия} (‹=== замените операторы CASE ссылкой на каталог)
Пока аналитики, специалисты по данным и операторы ВСЕ ссылаются на этот объект в своих запросах, одно изменение в каталоге обновит логику всех одновременно, и каждый получит обновленные правила в следующий раз, когда они обновят запрос. Отлично!
2. Научите свою команду ловить рыбу (создайте стандартные параметризованные запросы, которые побуждают ваших пользователей к самообслуживанию)
Многие SQL сегодня попадают от «автора» в руки бизнес-пользователей, которые в основном выполняют SQL для извлечения необходимых им данных. Как и в приведенном выше примере CASE, по мере изменения бизнес-логики трудно гарантировать, что это дойдет до всех нижестоящих потребителей. И когда вы передаете оператор SQL, нет никакой гарантии, что эти «полезные» аналитики на принимающей стороне не изменят запрос каким-либо образом, который, по их мнению, лучше подходит для их целей.
Каталог Aginity Team решает обе эти проблемы при поддержке сети «потребителей» SQL. Вместо того, чтобы давать необработанный SQL аналитику, я могу просто поделиться с ним ссылкой:
ВЫБРАТЬ *
ОТ @{Каталог команды/Профиль клиента}
Это гарантирует, что автор контролирует определение этого профиля клиента и поддерживает логику в одном месте. И это становится еще более гибким при использовании параметров. Aginity Team и Aginity Pro поддерживают параметры, которые затем предлагают пользователю заполнить во время выполнения. Поэтому, если бы этот профиль клиента менялся из года в год, я мог бы предложить пользователю указать интересующий его финансовый год:
3. Сведите к минимуму хранилище данных (стандартизируйте многие часто используемые JOIN в нормализованных базах данных)
Вы когда-нибудь чувствовали, что тратите 80% своего времени, соединяя одни и те же столы снова и снова? Когда я работал в сфере медицинского страхования, если бы у меня был 1 доллар каждый раз, когда я присоединяюсь к ПРЕТЕНЗИИ к УЧАСТНИКУ, ПОСТАВЩИКУ, ДИАГНОЗУ, УСЛУГЕ и т. Д., Что ж… скажем так, я бы больше не переживал о своей франшизе.
Каталог в Aginity Pro/Team также отлично подходит для этого. Думайте об этих СОЕДИНЕНИЯХ как о «блоке», который вы можете вызывать в любое время, когда вам понадобятся поля из этих таблиц.
ВЫБЕРИТЕ @{TypicalMedicalClaimsFields}
ОТ @{MedClaims Block}
ГДЕ Patient_ID = $some_value
Похоже, что печатается намного меньше, не так ли:
ВЫБРАТЬ *
ОТ
MED_CLAIMS_FACT МФ
INNER JOIN MEMBER_DIM MD ON MF.MEMBER_ID = MD.MEMBER_ID
INNER JOIN PROVIDER_DIM PD ON MF.PROVIDER_ID = PD.PROVIDER_ID
ВНУТРЕННЕЕ СОЕДИНЕНИЕ DIAGNOSIS_DIM DD ON MF.PRI_DIAG_CD = DD.DIAG_CD
INNER JOIN FACILITY_DIM FD ON MF.FACILITY_ID = FD.FACILITY_ID
ГДЕ
Patient_ID = $some_value
4. Упрощение сложного кода (уродливые подвыборки и соединения, которые вы часто используете)
Большие вложенные вложенные команды SELECT очень неудобны: они затрудняют чтение и запись SQL и часто приводят к проблемам с кардинальностью. Думая об этих подзапросах как о «множествах» или «представлениях» в вашем каталоге, вы действительно легко получите нужную логику и создадите очень удобочитаемую логику. Например:
ВЫБЕРИТЕ a.*, b.*
ОТ
CUSTOMER_MASTER_TABLEа
ВНУТРЕННЕЕ СОЕДИНЕНИЕ @{Продажи по клиентам — на прошлой неделе} b
ON a.customer_id = b.customer_id
ГДЕ
a.customer_id в (@{Исчезнувшие клиенты — в прошлом месяце})
5. Выбор общих полей (из больших таблиц, которые вы используете)
Это здорово, когда ИТ-отдел предоставляет вам киоск данных со всеми атрибутами, которые могут вам понадобиться для анализа на минимально возможном количестве таблиц. 10% странных вопросов, которые вы получаете, означают, что у вас, вероятно, есть то, что вам нужно. Но для 90% довольно распространенных вопросов я часто выбираю один и тот же набор из 15 столбцов из более чем 150 вариантов. Поэтому я снова и снова вставляю один и тот же большой блок столбцов в свой запрос.
Создание записи каталога для этого значительно упрощает вставку этих общих полей и их изменение в одном месте всякий раз, когда изменяется имя столбца или когда что-то добавляется.
ВЫБРАТЬ
@{Основные данные продукта — общие} (15 столбцов, которые я всегда выбираю в основной таблице)
,product_class_code_4
,product_class_code_5
,и т.д.
ОТ
PRODUCT_MASTER PM
ГДЕ
Discontinue_DT › $prompt_discontinue_date
Ладно — ладно, это топ-5 кейсов, как вам может помочь каталог активной аналитики! Сообщите нам свое мнение.
