#sql #sql-server #etl
#sql #sql-сервер #etl
Вопрос:
Набор данных, который я получаю для обычных целей обновления, содержит поле даты, которое на самом деле является VARCHAR .
Поскольку это будет поле для индексирования / поиска, у меня остается…
1) Преобразование поля в DATETIME и проверка и нормализация значений данных при обновлении
или…
2) Оставляю данные как есть и формирую свои запросы с учетом различных допустимых форматов даты, т. Е. ГДЕ DateField = ‘CCYYMMDD’ ИЛИ DateField = ‘MM / DD / CCYY’ ИЛИ ….
Обновление будет осуществляться ежемесячно; «очистка» данных увеличит время цикла ETL примерно на 35%. Все мои запросы к полю даты были бы равны; мне не нужно выполнять поиск по диапазону. Кроме того, я работаю на одного человека, поэтому, чем больше свободного от общего решения, тем лучше.
Итак, какой сценарий мне лучше использовать? Все мнения приветствуются.
Ответ №1:
Я думаю, что это отличный вопрос. Вот мое мнение:
Я твердо верю в идею, что в долгосрочной перспективе вы сэкономите больше времени и будете испытывать меньше головной боли, используя типы данных для той цели, для которой они были предназначены. Это означает даты в полях даты, символы в символьных полях и т.д. Если вы выберете вариант 2, вам нужно будет не забывать кодировать для всех различных возможных форматов даты каждый раз, когда вы запрашиваете таблицу. Если вы отложите это и вернетесь через год, собираетесь ли вы вспомнить?
Напротив, если вы используете поле даты и выполняете предварительную работу в процессе ETL по правильной обработке дат, вы всегда будете знать, как взаимодействовать с этим полем. И я даже не вдаюсь в последствия для производительности.
И в этом случае я не уверен, что вы даже увидите краткосрочную выгоду. Если в исходных данных существует, например, 5 различных возможных форматов даты, вам нужно будет учитывать их тем или иным способом; либо в ETL, либо в выходных запросах. Код для преобразования этих 5 форматов в ETL не является существенно более сложным, чем код для управления этими 5 форматами в выходных запросах.
И если данные могут буквально поступать в бесконечном количестве форматов, у вас в любом случае возникнут большие проблемы. Либо ваш ETL сломается, либо ваши запросы сломаются. Это, в определенной степени, непреодолимая сложность.
Я бы посоветовал вам потратить время на кодирование правильных преобразований в вашем ETL. Но сделайте себе одолжение и закодируйте этап предварительной обработки, который идентифицирует даты в форматах, которые не будут преобразованы должным образом, и предупреждает вас о них. Если вы видите шаблоны; то есть, если какой-либо формат отображается более одного раза, закодируйте для него преобразование. Со временем вам придется вручную очищать все меньше и меньше этих неприятных дат. Если повезет, ваши 35% упадут до 5% или меньше.
Удачи!
Ответ №2:
Вам лучше очистить данные. Первые даты, которые не являются хорошими датами, бессмысленны, поэтому их бессмысленно хранить. Во-вторых, исправить неправильный выбор типа данных позже сложнее, чем никогда его не делать. Выполнение запросов будет не только проще, но и быстрее, чем при использовании varchar. И такие вещи, как упорядочение, будут работать правильно, а также функции даты. В-третьих, я не могу представить, что очистка этого добавила бы так много к вашему импорту, я постоянно очищаю данные, и это не является проблемой. Но если это произойдет, то очистите данные в промежуточной таблице, которую не использует ни один другой процесс (чтобы вы не влияли на пользователей в prod), а затем выполните загрузку в таблицы prod из nice clean data.
Ответ №3:
Предварительно очистите данные и сохраните даты как dates.
Я работаю с системами, которые хранят даты в виде строк, и, похоже, существует неограниченное количество способов хранения дат. Это очень затрудняет создание запроса, который будет работать с будущим новым форматом даты.
Если вы храните даты в виде строк, вам следует применить ограничения, чтобы убедиться, что данные хранятся в правильном формате. Или просто преобразуйте строки даты в даты и позвольте базе данных самой применять допустимое ограничение даты. Обычно лучше позволить базе данных выполнять всю работу за вас.
Ответ №4:
Определенно лучше очистить данные и загрузить в столбец даты, поскольку это обеспечит целостность.