Господа.
На проекте BW возникла глобальная проблема: в исходной системе (не SAP) есть КЛЮЧЕВЫЕ поля длиной более 60 символов. Что делать?
Соединение признаков не подходит, т.к. длина соединения тоже не более 60 символов.
Применение атрибута подходит, но если первые 60 символов ключа одинаковые, то это не выход.

ЗЫ. Речь идет именно о КЛЮЧЕ, а не о длине текста.

Помогите! Или просто посочувствуйте
Спасибо.

Выход 1: Бейте на 2 (3, 4, ...) части. На каждую часть свой отдельный признак длиной 60. В отчетах склеивайте.
Выход 2: перекодировка. Каждый длинный ключ при загрузке перекодируется в поле длиной 60. Если нужно, то длинный ключ - в атрибуты этого поля длиной 60 (2, 3, ... атрибута).

Мы склоняемся ко второму варианту, хотелось бы спросить - Вы им пользовались? Или просто решили поразмышлять на заданную тему?
Если пользовались, то раскройте тайну алгоритма перекодировки, хотя бы принцып...
Спасибо.

Гм... Такую злобную перекодировку делать (тьфу 3 раза через плечо) не приходилось Ну алгоритм то можно придумать... Самый тупой вариант - на стороне исходной системы пронумеровать (1, 2, 3 и т.п.) все длинные коды, номер внести в справочник, тоже на стороне исходной системы. При возникновении нового значения длинного кода в исходной системе обязательно давать новый номер, наименьший свободный.

Манипуляции с исходной системой полностью исключены.
Я предположил, что под перекодировкой вы подразумевали сжатие кода ">60" в код "<=60"....
Ваш в"самый тупой вариант" не подходит, т.к. потребует огромных доработок исходной системы, которые ВООБЩЕ исключены.

Необходим нерандомный алгоритм сжатия небольшой строки (до 256) к длине не более 60, с гарантированным неповторяющимся результатом при сжатии различающихся строк.

Господа, есть гениальные идеи? Типа, арифметическое сжатие, двоичные деревья и т.д. и т.п....?

Алгоритм то можно придумать Только вот не пойму, а смысл какой?
Ну, хорошо, сожмете вы в 60. Дальше что? В отчетах у вас везде будут вылазить непонятные "сжатые" коды... Почему бы не пойти по варианту 1? Ведь все равно итог то будет одинаковый, чтобы в отчете вывести длинный код из исходной системы, нужно будет "склеивать" части по 60 символов...

Мне кажется, что по 2-му варианту будет меньше гемороя с отчетами...
В отчете по 2-му варианту выводим атрибуты (Вы же сами говорили, что если нужен исходный код полностью, то кладем его части в атрибуты ). с атрибутами ОДНОГО признака, ИМХО, проще работать чем с набором признаков.

можно воспользоваться например таблицами перекодировки аля
часть ключа
0000 = A
0001 = B
...
принцип думаю понятен
тогда ключ BA развернется в 00010000
ну а поиск эффективных алгоритмов перекодировки для вашего случая это уже совсем другая тема.

1. Таблица перекодировки. Типа псевдо-SID. Это самый надёжный путь.
2. Использовать сжатие в короткую форму получение хеш-функции.

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

можно ведь таблицу перекодировки сделать и на стороне BW...

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