Комментарии 6
Хотелось бы понять, где именно в статье показано использование Python, R, ETL для "очистки данных"? Зачем эти абсолютно бессмысленные упоминания, выставление тегов и размещение в хабах, никак не относящихся к содержательной части статьи? Информационный мусор в надежде привлечь посетителей?
И где вообще объявленная в заголовке статьи "очистка перед загрузкой в хранилище"? Вся содержательная часть статьи (после отжима воды) - три SQL'ных костыля, применяемых к уже загруженным в хранилище данным и необходимых только потому, что структура реляционной базы данных разрабатывалась абсолютно некомпетентными "специалистами".
Первый запрос не нужен, т.к. недопущение дублей автоматически реализуется на уровне создания таблицы БД - добавлением уникальных индексов и/или триггеров.
Второй запрос не нужен, т.к. дефолтные значения для столбцов задаются, опять же, при создании таблицы. И если в столбце таблицы не должно быть NULL, такой столбец изначально создаётся с модификатором NOT NULL.
Но если два первых запроса ещё более-менее понятны (напахали со структурой, бывает, но в этом случае корректирующий запрос выполняется единственный раз - перед внесением правок в структуру таблиц), то третий SQL-запрос вызывает, мягко говоря, недоумение... Во первых, функция ISDATE существует только в MS SQL Server и не может иметь никакого отношения к хабу PostgreSQL (в котором статья находится в настоящий момент). Во вторых, если столбец даты имеет тип DATE, то весь этот запрос абсолютно бессмысленен, т.к. никак не меняет данные в таблице. Но если столбец для хранения даты имеет тип VARCHAR, то это даже не некомпетентность, а невежество создателя таблицы.
P.S. Сама идея "очищать данные", записанные в реляционную СУБД - показатель непонимания автором того, что такое РСУБД. Реляционные базы предназначены для уже "очищенных" и полностью структурированных данных и использовать их для "сырых" данных - это как пытаться спилить столетний дуб ножовкой по металлу. Для хранения "сырых" данных предназначены совсем другие хранилища, не имеющие никакого отношения к РСУБД.
полностью с вам согласен - статья и теги - всё не так. Но. Во всевозможных ETL-процессах, где куча всяких csv-файлов загружается в сырые таблицы и только потом из них создаётся/воссаздаётся или актуализируется настоящая модель (Stagng Area). То есть такое имеет место быть, но это никак нельзя назвать "Очистка данных перед загрузкой в хранилище"- вот тут вы опять правы.
Вы не рассматриваете тот, вариант, что не все могут быть такими прошаренными в этой теме. Статья заявлена, как простая, а не докторская.
Никто не писал в статье, что мы рассмотрим все варианты кода на все языках программирования. Если в этом есть необходимость, то мы отдельно сделаем, более расширенный вариант с подробным рассмотрением кода.
Статья заявлена, как простая, а не докторская.
Статья называется: "Очистка данных перед загрузкой в хранилище. Подробное руководство с техническими деталями". В реальности же в статье нет ни "подробного руководства", ни "технических деталей". И даже о том, как именно надо очищать данные до загрузки, в статье нет ни слова. Зато все три примера демонстрируют очистку данных после загрузки в хранилище. Причём очистка производится модификацией данных в таблице, из которой эти данные были прочитаны. Подобные запросы прекрасно смотрелись бы в статье "Как нельзя производить очистку данных", но предлагать такое как образец очистки...
Если статья рассчитана на "непрошаренных", то это не повод обещать в заголовке то, чего в статье ни в каком виде нет, и использовать заведомо низкокачественные примеры, никак не соответствующие теме статьи.
Никто не писал в статье, что мы рассмотрим все варианты кода на все языках программирования.
Если вы не рассматриваете примеры кода, то зачем упоминать языки программирования, библиотеки, программные пакеты? Вставленные только для того, чтобы эти названия присутствовали в тексте статьи - в окружении воды, не несущей никакой реальной информации.
P.S. Спасибо, что поправили теги и хабы.
Очистка данных перед загрузкой в хранилище. Подробное руководство с техническими деталями