«Существующие записи могут иметь дублирующие записи, основанные на данных 4 поля т.е. одинаковые значения для счета, дата, сумма и частностей для двух или более действительных сделок, но он уверен, что эти записи являются действительными даже с повторяющиеся значения. "
Но как может кто-нибудь сказать, если в загруженных данных или исходных файлах нет знака уникальности? Что означает справедливость?
«Теперь для загрузки отсутствуют записи, мы должны определить, если запись уже загружен или нет, так что мы не нагружают запись, которая уже загружен.»
Без существующего источника уникальности вы не сможете это сделать. Поскольку у вас есть две строки для данной комбинации (Account, Date, Amount, Particulars), и все в порядке, каковы правила определения того, что третий экземпляр (Account, Date, Amount, Particulars) - это запись, которая уже была загружена, следовательно, недействительна или запись, которая не была загружена, следовательно, действительна.
«Таким образом, для меня, это выглядит очень трудно понять, если запись уже загружена на основе этих полей. Я вижу, как за пределами этих полей»
Ты право сказать, что решение не может быть найдено в данных, как вы его описываете. Но решение на самом деле очень просто. Вы обращаетесь к людям, которые подтвердили достоверность загруженных записей и представили им список этих дополнительных записей. Они смогут использовать свои навыки и суждения, чтобы сообщить вам, какие записи действительны, и вы загружаете их.
"это мой долг, чтобы найти решение"
Нет, это не ваша обязанность. В настоящее время долг лежит на плечах владельца данных, чтобы точно определить их данные, и это включает определение бизнес-ключа. Это те, кто отменил свои обязанности.
В этих условиях у вас есть три варианта:
- отказывается загружать какие-либо дополнительные записи, пока владелец данных не делает свой долг.
- Загрузите все записи, представленные вам для загрузки без какой-либо проверки.
- Используйте синтаксис ужасного NOVALIDATE.
NOVALIDATE - это способ обеспечения соблюдения правил валидации для будущих строк, но игнорирование нарушений в существующих данных. В основном это технический клочок для политической проблемы.
SQL> select * from t23
/
COL1 COL2
---------- --------------------
1 MR KNOX
1 MR KNOX
2 FOX IN SOCKS
2 FOX IN SOCKS
SQL> create index t23_idx on t23(col1,col2)
/
Index created.
SQL> alter table t23 add constraint t23_uk
unique (col1,col2) novalidate
/
Table altered.
SQL> insert into t23 values (2, 'FOX IN SOCKS')
/
insert into t23 values (2, 'FOX IN SOCKS')
*
ERROR at line 1:
ORA-00001: unique constraint (APC.T23_UK) violated
SQL>
Обратите внимание, что перед добавлением ограничения необходимо предварительно создать уникальный код. Если вы не сделаете этого, база данных создаст уникальный индекс и переопределит предложение NOVALIDATE.
Я описываю NOVALIDATE как ужасное, потому что это так. Он испепеляет повреждение данных в базе данных. Но это самое близкое вам решение.
Этот подход полностью игнорирует понятие «действительность». Поэтому он отклонит записи, которые, возможно, должны были быть загружены, поскольку они представляют «действительное» n-е вхождение (Account, Date, Amount, Particulars). Это неизбежно. Хорошей новостью является то, что никто не сможет сказать, потому что не существует определенных правил для установления действительности.
Какой бы вариант вы ни выбрали, важно, чтобы вы четко объяснили это своему боссу, владельцу данных, боссу владельца данных и тому, кому вы считаете нужным, и получите их письменное согласие. В противном случае, в какой-то момент люди обнаружат, что база данных заполнена повторяющимися строками, или кто-то будет жаловаться на то, что «действительная» запись не была загружена, и все это будет вашей ошибкой ... если у вас нет подписанного фрагмента бумага с разрешением от соответствующей верхней латуни.
Успехов
Haki's suggestion of using MERGE имеет тот же эффект, как NOVALIDATE, потому что она будет загружать новые записи и подавить все дубликаты. Тем не менее, это еще больше излома: он вообще не затрагивает понятие уникальности. Любой, у кого есть доступ INSERT или UPDATE, все равно сможет иметь любые строки, которые им нравятся. Таким образом, этот подход будет работать, только если вы сможете полностью заблокировать привилегии в этой таблице, чтобы его данные могли обрабатываться только через MERGE и ни один другой DML. Зависит ли постоянная уникальность. Опять же, бизнес-решение.
или, возможно, 3 колонки - без «суммы». –
Невозможно, так как я заявил, что эти столбцы можно просто дублировать для двух или более действительных транзакций – bjan
@ypercube - возможно. Но не видя данных, которые могут сказать? – APC