Abhijit Ghosh Ответов: 1

Как реализовать эти проверки с помощью SQL-запроса

Сегодня у меня есть сценарий, в котором я немного застрял. У меня есть данные, как это ниже моего источника источника таблицу Oracle(выборочные данные)
ID,NAME,SALARY,BIRTHDAY
1,ABHIJIT,2000,17/12/1990
2,ROHIT,-2000,13/11/1988
3,MOHIT,500,2075-575-43

Сейчас Salary во 2 - м ряду находится отрицательный и BIRTHDAY в 3-й строке находится недопустимый формат(допустим ММ/ДД/гггг). И 2-я, и 3-я строки должны идти в INVALID_EMPLOYEE, а 1-я запись должна идти в VALID_EMPLOYEE.

В исходном файле формат даты идет как ДД/ММ/гггг. Который я должен преобразовать в формат MM/dd/yyyy, а также проверить, является ли формат даты, входящий в исходный файл, dd/mm/yyyy или нет.

Salary не должно быть меньше 0. Исходная таблица все столбцы находятся в строке и в целевой таблице ID является целым числом,NAME как VARCHAR2(255), SALARY это число и BIRTHDAY это дата.

Я обрабатывал все это в моем проекте ЛЭП. Поэтому я пытаюсь протолкнуть все это в запрос, чтобы повысить производительность.Любая помощь очень ценится

Что я уже пробовал:

Я уже сделал те, которые используют мой ETL.

1 Ответов

Рейтинг:
1

OriginalGriff

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

В частности, ваша дата является проблемой, потому что невозможно получить недопустимую дату в БД - все ваши запросы должны использовать параметризованные запросы, которые передают проверенный объект DateTime - единственный способ получить "плохую дату" в БД-это передать ее в виде строки, а это подразумевает конкатенацию строк, которая делает всю вашу систему уязвимой для проблем SQL-инъекции, которые могут повредить всю вашу БД.

Кроме того, существует разделение проблем POV: отрицательная зарплата-это проблема бизнес-уровня, а не проблема БД, и опять же, она должна быть подтверждена и рассмотрена на уровне бизнеса или даже презентации, а не подаваться на уровень данных, к которому уже слишком поздно что-либо делать.

Я думаю, что вам нужно переосмыслить это - и, вероятно, изрядное количество остальной части вашего приложения, если SQL-инъекция возможна.

MadMyche

Именно так. Работа базы данных-это data CRUD; это приложение, использующее работу БД для проверки данных. Добавление проверки на уровень БД - это просто перекладывание ответственности, и ИМХО неправильный путь. Я бы переместил его в источник данных, чтобы дать вам правильную информацию.