А никто не пробовал такой способ (sm30 > Таблица > Поиск диалога ведения (Ctrl+F1) )?

Полный текст статьи доступен по ссылке:
stepanovd.com/article_2013_4_tp.html

Полный текст статьи доступен по ссылке:
stepanovd.com/article_2013_4_tp.html

Так лучше?

Спасибо за полезную статью, но название ИМХО не соответствует содержимому. Не баг ли это?

На мой не искушенный взгляд, 2/3 статьи - перевод из хелпа и референс гайда, еще одна треть - скриншоты из эклипса.
Что было бы действительно интересно, как мне кажется:
1) сравнение методов партицирования, описание в чем преимущество того или иного метода.
2) Какие плюсы и какие минусы каждого из методов на разных прикладных задачах
3) описание не освещенных в мануалах аспектов, как-то: а) что будет с данными, если разделение на партиции\слияние партиций происходит на таблице с данными, б) сколько уровней секционирования может быть максимально
 
От себя хочется добавить: не смотря на описание в хелпе (и в статье), что для hash и range секционирования надо что бы в таблице был первичный ключ, SP09 позволял создавать секционирование на таблице даже в его отсутствие.

А разве она не на конкретном сервере приложений работает? Если пользователь на другом (ну в случае, если их несколько, конечно).

===
Опытные SAP-консультанты сейчас стали задумываться о разработке собственного учебного курса
===
Не а, никогда над таким не задумывался :-) пока кое кто не придаст соответствующего пинка и направления, еж, он ведь как известно - птица гордая, сам не полетит :-)

А почему падает? Доступ насколько мне известно выполняется как раз на сжатых данных, а уже после получения записей из БД происходит их распаковка.

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

Виталий,
боюсь у Вас очень узко-потребительское представление об iPhone...

Спасибо, Олег! Интересная тема.

Боюсь поколоночное хранение данных это больше заслуга Sybase IQ, нежели HANA. Безусловно SAP HANA включает это функционал.
 
P.S. сугубо личное представление о HANA, как об IPhone среди корпоративных систем. Хорошее сочетание ранее известных и точечно используемых технологий, которое сумели вовремя правильно преподнести широкой публике.

Спасибо, за первую часть статьи до рис. 4 включительно. Она была интересна и полезна.
А вот дальше появились вопросы. Предполагаю, что просто опущены некоторые детали, которых мне не хватило.
Например, в начале написано "Предположим, для выполнения задачи используется процессор с четырьмя потоками (threads).", а дальше описывается схема в которой активны только 2 потока. Предполагаю, что программно, это может обрабатываться и 4 потоками, когда 2 работают, 2 ждут, но зачем для этого процессор с 4-мя потоками, если достаточно 2-х?
И подскажите, а чем отличается обработка Scan, Aggregation и Join в SAP HANA от аналогичных операций в Oracle?

WEBI позволяет опубликовать на WEB (прошу прощения за тавтологию) или работать с отчетом из мобильного приложения(Business Objects Mobile). В целом думаю выбор инструмента зависит от того какая у Вас задача и от кол-ва пользователей отчета.

В общем согласен! в моем случае нужно было опробовать новый вариант планирования которого не было в КХД... т.е. сделать достаточно надежный прототип.

ой... в статье много достаточно грубых ошибок.
 
Предполагаю, что на словах этот материал звучит просто и понятно, и для быстрого вхождения в тему так оно и должно быть. Но в печатном виде его лучше не читать, некоректные утверждения почти в каждом абзаце.
 
Чтобы не повторяться. Мои корректировки в дополнение к комментарию Олега Точенюка:
1) абзац 2. SAP GUI, как минимум представлена в виде 3-х версий. 2 указаны вами и 3-я - WebGUI, когда ABAP-код на стороне сервера приложений не меняется и используется тот же, что и для запуска через SAP GUI, а функцию визуализации на стороне компьютера пользователя выполняет браузер.
Дополнительно есть куча доп. программ, которые использую функционал SAP GUI в своих целях, например, Netveawer Business Client и Eclipse с SAP допоплнениями.
2) абзац 3. "Каждая программа запускается с помощью уникального кода, который в SAP ERP называется транзакцией." - слово код лучше заменить на слово идентификатор, чтобы не было путаницы между кодом в абап программе и именем транзакции.
3) абзац 5. лучше так никогда не говорить. Пользователи работающие в разных отделах работают с одними и теми же данными, потому что они используют одну БД. Это возможно, как при двух уровневой архитектуре, так и при одноуровневой. Пример одноуровневой, если каждому пользователю выдать свои часы в течение рабочего дня, когда он может вбивать данные в программу или посадить девушку секретаря, которая будет вбивать и выводить данные для разных пользователей. Технически программа будет использовать одноуровневую модель. Трехуровневая модель используется для других целей. (dic.academic.ru/dic.nsf/ruwiki)
 
4) абзац 6. Не согласен, что это недостаток. Это как раз та причина,  почему разные пользователи работают с одними и теми же данными. Если бы была возможность работать без установленного соединения устройства пользователя с сервером приложений и БД, то был бы риск, что
а) пользователь будет работать с устаревшими данными, т.е. пользователь только формирует отчет, а в БД уже давно другие данные и у сервера нет возможности сказать клиенту, что данные обновились, а у клиента нет возможности это проверить и предупредить пользователя;
б) два пользователя вносят изменения и сидят без соединения своего компьютера с серверов, потом другие пользователи еще вносят изменения в эти же данные. Что делать, когда изменения появятся? кому отказать?
 
P.S. прошу прощения за орфографические и грамматические ошибки в комментарии, писал на скорую руку.

PowerPivot Excel содержт в себе более богатые возможности. И бесплатно

мне не понравилась фраза "факт в кубе, а план в excel"... займитесь сначала построением нормального КХД, а потом уже наворачивайте "спагетти" из кривых решений.

Артем, про коды налогов мы уже говорили
sapexpert.co.uk/move-tax-codes-between-sap-systems