Age: 170 Joined: 04 Oct 2007 Posts: 1218 Location: Санкт-Петербург
Posted: Wed Jan 30, 2008 3:16 pm Post subject:
ИМХО, если вставка нового года вставляет новый документ в нужную позицию таблицы, а не в конец, значит работает автоматическая сортировка по ключу на уровне базы. Поэтому если и будет нарушена последовательность buzei при insert, она автоматом изменится.
Last edited by vga on Wed Jan 30, 2008 3:18 pm; edited 1 time in total
Проверил по методу VGA, последовательность не изменилась, но в DEV нет документов в RFBLG более чем в 1 запись. вопрос то в том
можно ли "безнаказанно" использовать BINARY SEARCH.
Age: 170 Joined: 04 Oct 2007 Posts: 1218 Location: Санкт-Петербург
Posted: Wed Jan 30, 2008 3:20 pm Post subject:
Mike1, я сначала не правильно понял твое сообщение. Ты имел ввиду порядок buzei. Подправил, но идея вроде как та же самая.
Если мое предположение верно, то BINARY SEARCH можно
По моему Сап нигде не обещает такой порядок записей... кажется все таки лучше не рисковать, 1000 раз она будет отсортирована как ожидаете, а разок - немножко не так...
2 Armann
так я тоже не нашел
2 vga
я говорю про чтение только одного документа, база данных тут не причем,
это скореее вопрос по распаковке упаковке кластера на уровне сап.
Age: 170 Joined: 04 Oct 2007 Posts: 1218 Location: Санкт-Петербург
Posted: Wed Jan 30, 2008 3:54 pm Post subject:
mike1 wrote:
2 vga
я говорю про чтение только одного документа, база данных тут не причем,
это скореее вопрос по распаковке упаковке кластера на уровне сап.
Я так понял, что вопрос сводился к тому, какая последовательность при селекте будет, если при записи сначала сделали insert 2 позиции, а потом 1 ?
ИМХО, тут не важно, новый документ или новая позиция. В кластере это все равно новая запись. Пример с годом показателен, что новая запись вставляется в позицию, отсортированную по ключу, а не в конец кластера. Значит и селект вернет записи отсортированни по полному ключу, включая позиции, потому что они так расположены в кластере (или так работает "распаковка кластера на уровне сап."). Проверил в DEV.
На недокументированные возможности закладываться не стал.
Объявил t_bseg cортированной таблицей, на копейки оказалось быстрее, чем использование оператора sort.
Зы а запрос к RFBLG идет с ORDER BY "MANDT" , "BUKRS" , "BELNR" , "GJAHR" , "PAGENO"
В ходе поисков обнаружилось, что если для конкретного документа сначала считать bseg а потом bset se30 показывает 2 обращения к базе, а st05 только 1. Интересно а до 6.20 такая интеллектуальность была?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
All product names are trademarks of their respective companies. SAPNET.RU websites are in no way affiliated with SAP AG. SAP, SAP R/3, R/3 software, mySAP, ABAP, BAPI, xApps, SAP NetWeaver and any other are registered trademarks of SAP AG. Every effort is made to ensure content integrity. Use information on this site at your own risk.
