Как проверить, если дата действительна и в правильном формате в оракуле, чтобы вставить?

Question

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

     select to_date(dob,'dd/mm/yyyy') from table

Это не будет работать в большинстве случаев, как данныеможет быть таким же, как показано ниже, но он может быть перемешан в другом формате. У меня есть тысячи плюс таких записей, и мне интересно, сможет ли он работать через SQL-запрос с использованием регулярных выражений (я думал, может быть)

Answer 1

Одним из решений являются регулярные выражения:

select (case when regexp_like(dob, '^[0-9]{1,2}/[0-9]{1,2}/[0-9]{4}$'
             then to_date(dob, 'dd/mm/yyyy') 
             when regexp_like(dob, '^[0-9]{4}/[0-9]{2}/[0-9]{2}$'
             then to_date(dob, 'yyyy/mm/dd') 
             when regexp_like(dob, '^[0-9]{4}-[0-9]{2}-[0-9]{2}$'
             then to_date(dob, 'yyyy-mm-dd') 
        end)
from t;

Однако я не очень рекомендую это. У вас моделирование данных проблема. Вы сохранили date в виде строки, и это фундаментальная проблема. У вас нет контроля над входами, поэтому вы не знаете, относится ли 3/7/64 к 7 марта или 3 июля.

Вам действительно следует исправить таблицу, когда данные input .

Answer 2

Функция Oracle TO_DATE () довольно проста: ей все равно, используем ли мы '/' или '-' в качестве разделителя даты в маске формата. Поэтому я предпочитаю использовать TO_DATE (), а не регулярные выражения, поскольку они лучше выражают намерения и их легче читать: я пытаюсь преобразовать строки в даты, и вот форматы, которые я ожидаю. Кроме того, встроенные в Oracle функции SQL более производительны, чем регулярные выражения, что имеет значение при массовых операциях, таких как запуск ETL хранилища данных.

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

function cast_to_date (p_str in varchar2) return date is
  d date;
  masks sys.dbms_debug_vc2coll := sys.dbms_debug_vc2coll ('dd-mm-yyyy', 'mm-dd-yyyy', 'yyyy-mm-dd');
begin  
  for idx in 1..masks.count() loop
    begin
      d := to_date(p_str, masks(idx));
      exit;
    exception
      when others then
        d := null;
    end;
  end loop;  
  return d;
end;

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

Вот демонстрация на db <> скрипте этого подхода в действии . Обратите внимание, что я добавил еще несколько строк ввода к вашему образцу.

---

большинство дат совпадают, но имеют другой формат и одну из дат недопустимы.

На самом деле три из восьми дат недействительны, и еще три могут быть либо месяц-день-год или день-месяц-год . Это означает, что вы можете быть уверены, что 25% дат в выборке верны. Учитывая такой процент попаданий, вы тоже должны с подозрением относиться к ним: конечно, это даты, но они правильные? И, наконец, можете ли вы доверять любым данным, которые эта исходная система передает вам? Как вы можете быть уверены, что они только кавалеры с этой одной колонкой и строгие со всеми остальными колоннами? Держу пари, что «имя, фамилия и номер телефона» также полны хитрых значений.

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