SQL - дата хранится как varchar, но отформатирована как юлианская дата

Question

Я просматривал похожие посты и не нашел точную проблему. По сути, я только начал свою работу в компании, которая сейчас строит свою базу данных с подрядчиками. Каждое из наших полей даты хранится в юлианском формате "20190101", но они отформатированы как Varchar вместо DateTime.

Это очевидно проблематично для использования функций, связанных с датой, в SQL. В конечном итоге я планирую поднять ноги наших подрядчиков к огню и попросить их изменить его. Но, основываясь на моих исследованиях, я не могу найти никакой реальной причины, по которой база данных будет создана без использования формата DateTime для дат, отличных от лени.

Есть ли законная причина хранить форматы даты и времени как varchar? И во-вторых, если это то, с чем я застрял, может ли кто-нибудь объяснить мне, что я могу сделать, чтобы сделать это в работоспособном формате? В большинстве моих запросов я собираюсь получить данные за предыдущие 365 - 730 дней.

В настоящее время я получаю сообщение об ошибке «Преобразование типа данных varchar в тип данных datetime привело к значению вне диапазона». в следующей строке кода:

WHERE Promise_Date > DATEADD(year,-1, GETDATE())

Answer 1

Вы должны найти причину сбоя преобразования:

SELECT Promise_Date
FROM t
WHERE TRY_CONVERT(date, Promise_Date) IS NULL;

А пока сделайте преобразование явным:

WHERE TRY_CONVERT(date, Promise_Date) > DATEADD(year,-1, GETDATE())

Как правило, нет веских причин для сохраненияданные в виде строки. Если вы используете строку, то YYYYMMDD - очень хороший выбор. SQL Server всегда будет правильно конвертировать его. В вашем случае у вас неверные значения.

В некоторых случаях даты и не даты должны храниться в одном и том же поле. Например, однажды я работал в среде, где производные ценообразования оценивались на определенную дату, но их также можно было указать как «закрытие Нью-Йорка» или «открытие Лондона» или что-то подобное, чтобы указать «деловые» даты.