Занятное замечание: "если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы"
 
Вы представляете что такое хеш доступ и как он реализуется при построении индекса? Вообще-то скорость доступа зависит не от длинны ключа (ну если мы не ассемблерный код хеш-функции анализируем и такты процессора с внутренними стеками да длину команд высчитываем), а от качества используемого алгоритма - хеш функции. Чем больше коллизий у алгоритма расчета тем медленнее поиск, так как выполняются различные дополнительные методы обхода коллизий и т.д.
 
PS: Не я понимаю что простое сложение байт строки в 10 символов и строки в 20 выполняется дольше, но мы то про базы данных, а не про что быстрее посчитается на уровне процессора и памяти.

Ну вы их читали, но по факту так ничего в примеры кроме вот этого вот: "являются скорее уж вредными советами" не привели, поэтому беседа как бы ни о чем. Хотя я предложил вам ранее это сделать на конкретных примерах, где по вашему или совет не тот или граната не той системы.
 
По повожу технического редактора, ну я писал, Александры Дублин и Яков Михалыч Басок редактировали, Василий Ковальский вроде как рецензировал, но если для вас это ни о чем не говорит, то фиг с ним, оригинал тоже подойдет, хотя именно это издание я не читал. Но если вы думаете что мне было нечего делать, просто пересказать своими словами приведенную вами ссылку, то я тоже не возражаю.
 
PS: По поводу статей, именно статей тут по абапу их вообще-то мало (кажется 2), вы наверное имеете в виду авторские колонки/блоги. Их конечно же кроме автора вряд ли кто редактирует. Кстати, сделайте свою колонки, а мы почитаем...

На мой не скромный взгляд: тест по хэшу ни о чем.
1) скорость измерения для хэш-таблы не коррелирует линейно с числом строк в таблице
2) речь идет о микросекундах, т.е. скорее всего это погрешности связанные с накладными расходами на обслуживание работы с таблой собственно, а не на поиск.
3) для чистоты замеров стоит исключить перекладывание найденных данных, использовав вместо INTO конструкцию TRANSPORTING NO FIELDS
4) если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы.
ЗЫ: Непонятно про рекламируемую книгу: зачем она, если есть первоисточники
sap-press.com/abap-performance-tuning_2092

Вы уж простите, я книгу Точенюка не читал. Но я читал его заметки по производительности с сайта sapforum.biz. Могу сказать, что там были моменты, которые, на мой взгляд, являются скорее уж вредными советами. Т.е. модель "дешево и сердито" конечно хороша, но не стоит забывать про "кроилово ведет к попадалову".
Изданная книга это конечно хорошо, но был ли у нее тех.редактор? На примере статей этого ресурса по ABAP, можно сказать, что они не подвергаются рецензированию и редактуре (да какая редактура, если даже орфографические и синтаксические ошибки в статьях не вычищены?)

печально то, что в СНГ только 2 нормальные книги на русском: Виталия Поцелуева и Олега Точенюка.
 
далеко нам уже до индусов и остальных - те книги пачками выпускают.

1) очень печально, если программер не может читать на английском хотя бы тех.литературу
2) - папа, зачем ты пьешь водку из горла? Возьми стакан!
   - Сынок, папе не нужны посредники!

4) книга на русском. и она дешевле :)

На мой не скромный взгляд: тест по хэшу ни о чем.
1) скорость измерения для хэш-таблы не коррелирует линейно с числом строк в таблице
2) речь идет о микросекундах, т.е. скорее всего это погрешности связанные с накладными расходами на обслуживание работы с таблой собственно, а не на поиск.
3) для чистоты замеров стоит исключить перекладывание найденных данных, использовав вместо INTO конструкцию TRANSPORTING NO FIELDS
4) если я ничего не путаю, то наиболее заметно скорость поиска по хэш табле зависит от собственно длины ключа таблы.
ЗЫ: Непонятно про рекламируемую книгу: зачем она, если есть первоисточники
sap-press.com/abap-performance-tuning_2092

Виктор, спасибо за Ваши публикации.
У меня вопрос относительно "инициация процедур создания новой записи ЕО при приемке на склад МТО вновь поступающего оборудования", рассматривали ли Вы в теории, возможность использования функциональности "серийные номера" для решения данной задачи, либо использовали СН на практике? Если отклонили СН, то по каким причинам?
Спасибо за ответ.

Разграничение полномочий на ввод и изменение данных вводимых вручную в рамках SAP-системы осуществлялось стандартным определением полномочий в рамках ролевой структуры. Объектами полномочий могут служить как технические объекты (ТМ и ЕО), организационные структуры (завод, цех, бригада), так и отдельные поля в документах. На уровне каналов связи (корпоративной интеграционной шины) обеспечивающих передачу данных разграничение полномочий определяется набором полномочий, которыми наделен пользователь как в системе SAP, так в MES. Для того что бы описать конкретную реализацию рамки настоящее колонки недостаточны. Мы можем обсудить эти решения в отдельной переписке с учетом вашей конкретной ситуации.
Мой e-mail vlehttsind@parma-telecom.ru

Добрый день! Вы в статье пишете "Часть данных передается в сообщения и документы измерения по каналам связи между MES-системами и SAP ERP, часть переносится программным путем из технологических режимов скважин, часть заносится вручную."
Подскажите, ставилась ли задача по обеспечению разграничения полномочий на ввод данных - т.е. чтобы подразделение, которое вводит данные в сообщение могло вводить и корректировать только "свои" данные сообщения и не иметь доступ например на изменение данных  перенесенных в сообщение из других систем. Если ставилась - подскажите как это реализовывалось? Спасибо.

"Оказывается, время поиска в хешированной таблице таки зависит от размера" - Таки не может, хеш-функция, на то и функция что она определяет положение записи, но ваше утверждение звучит так, что в зависимости от значений a, b и c, скорость расчета программой квадратичного уравнения ax^2 + bx + c = 0, таки разная и знаешь если это погонять, то в миллисекундах ты таки тоже получишь разные значения на вызов функции расчета такого уравнения.
 
Реклама, что ли: sapland.ru/books/rekomendatsii-po-optimizatsii-programm-na-yazike-abap.html там есть найденные на просторах SCN принципы организации внутренних таблиц, ну это чтобы не замерять, то что смысла замерять нет.