eNose

Вот есть шанс проявить знания.

Значит ситуация такая.
Наши тупые ораклоиды сваяли базу где айдишники на рекорды не формируются и они их сами придумывают для уникальности.
Как результат, там сборная солянка ссср: цифры, буквы, точки, тире и т.п. ерунда.
Вобщем обещали мне сделать уникальность.
Загружаю в скуль - хрена лысого.

Коллэйшен на сервере и базе "кэйс инсенситив".
А у этих придурков уникальные айдишники различаются по заглавным-прописным буквам.
Кинул им предъяву, они говорят что "такова их ораклиная сущносная уникальность".
Ломанулся к дизайнерам, говорю нужно коллейшен на базе, ну или хотя-бы на таблицах-полях поменять чтоб шрифт различало.
Они тоже в отлуп. Типа "не могу поступиться принципами"...

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

Теоретически на скуле это было-бы просто.

Что-то типа такого:И уникальность обеспечена.

Но проблема в том что мне нужно это делать "на лету", до вставки в базу, иначе будет много танцев с бубном.

Делаю в SSIS, а там BINARY_CHECKSUM функции нет.
Можно было-бы сваять Сишный модуль, но меня с ним тех-поддержка не пропустит.
Типа "это очень сложно" и "как мы это потом поддерживать будем?"

Значит идея такая: - Тянуть уникальное айди прямо с оракла.

Вот и вопрос: Есть там "BINARY_CHECKSUM" и если есть, то будет-ли выдавать достаточно уникальные значения и будут ли значения заглавных-прописных букв различаться?

ЗЫ Походу наши даже такого слова никогда не слышали, поэтому у них и такая уникальность.

Я их и сохраняю.
Там тупая задача.
В оракле они не могут отследить если запись была удалена.
Ну они её тупо удаляют.
Поэтому мне приходится каждый раз читать лист всех текущих айдишников чтоб вычислить какие записи были удалены и пометить их в моей базе как удалённые.

Спасибо. Сейчас попробую

Они тупые.

И тим лид из них.

Хэш не пошёл.
Не потому что он "не работает", а потому что когда ораклоиды увидели Скуль, то по дефолту он был кейс инсенситив.
Они так и подумали.

Поэтому "приняли к сведению"
Отсюда выросло решение "в скуле это нормально и так и должно быть!"

Как результат:
В кейс инсенситив поле будут валяться дупликаты, различающиеся регистром.

Я обьяснил что это только дело времени когда в ваши данные закрадутся ошибки.

На что мне сказали: - Это ты знаешь, мы знаем, никто больше не знает и проверить не сможет.

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

Я контрактор.
Делаю что велят.
Не удивлюсь если у меня зряплата раза в 2 больше чем у этого тим-лида.

Скрипт-то сработал.
Люди не сработали.

Ну я так и планировал.

Идея тоже хорошая.
Наверное даже лучше чем хэш.
Я-б так и сделал, но у этих идиотов требование чтоб каждый дебил, (т.е. они сами) мог трейсовать данные и проверять если что.

я-ж уже описал.
Повторяю:
Задача супер-стандартная:
1. Из оракла нужно ежедневно выкалупливать кучу таблиц.
2. Во всех этих таблицах есть "уникальное" поле и поля даты "последнего изменения"
3. Ежедневно нужно делать 3 операции
- Выкалупливать новые записи
- Обновлять изменённые
- Помечать удалённые как удалённые.

Решение простое:
1. Ежедневно высасываем из оракла все "изменившиеся" записи
- Выделяем новые и вставляем
- Выделяем имеющиеся и обновляем имеющиеся
2. Для каждой таблицы высасываем уникальное поле для ВСЕХ записей.
- Сравниваем список с уже имеющимся и помечаем исчезнувшие.

Проблема:
"уникальное" поле уникально в Оракле, но не уникально в Скуле, потому что по дефолту он не различает регистры, но никто об этом не знал (год 2020-й!) и сейчас менять "уже поздно".

Дополнительные требования:
1. Каждая "уникальная" запись в скуле должна быть читаема и сравнима с Оракловой базой, чтоб любой ораклоид мог посмотреть что всё "как надо".
Т.е. Никаких хэшей и т.п.
2. Даже на одно поле нельзя ставить коллейшен, чтоб оно различало регистры.
Т.е. им нужно, если есть 2 записи "ааа" и "ААА" то по запросу на "ааа" оно выдавало обе записи.

Решение:
Таки я поставил регистрово-небезразличный коллейшен на промежуточную табличку, в которую качаю из оракла и обновляю записи в обычных таблицах апдейтом.

Кривизна и косячность дизайна - очевидны.
Любой GROUP BY или какой поиск будут выдавать чёрти что, но никого это не волнует.

Праймер Кий нельзя сделать на не-уникальное поле, а если коллейшен допускает что разные регистры "одинаковы", то ключ просто не построится.

Про "тупых ораклоидов" мы уже говорили.
Они используют вложеные вьюхи - это их конь.

Скульщики вообще ничего не дают. С них даже молока не возьмёшь.