Posted: Fri May 16, 2008 4:39 pm Post subject: как правильно сделать Select
(4.6)
табличка имеет 1 ключевое поле и несколько индексов.
Как я понял имеет смысл строить запросы к базе по ключевым полям во Where , или полям в индексах. А затем во внутренней табличке отсекать все лишнее.
Читая исходники функции SAP натолкнулся на запрос который делает все наоборот... только пишет так:
Code:
Select
...
Where FIELD_1 IN RANGE_TABLE ...
Объясните это альтернатива? Корректно так строить запросы?[/code] _________________ (SAP) Система нипель... выпускает лучше, чем впускает!
Age: 170 Joined: 04 Oct 2007 Posts: 1218 Location: Санкт-Петербург
Posted: Fri May 16, 2008 8:27 pm Post subject:
Crystal_Ra wrote:
как работает RANGES как оператор я представляю.
Сорри. Пишите чаще, будем лучше знать ваши знания.
Думаю, что решение о возможности использования того или иного поля в условии должен принимать разработчик исходя из своего опыта. Если таблица небольшая или в свойствах ее указана необходимость кеширования на сервере приложений, то можно запросы строить и по неиндексируемым полям. Это не криминально.
При построении запросов для больших таблиц нужно учитывать несколько условий:
1) Скорость выполнения запроса.
2) Селективность по другим полям в условии where.
3) Частота использования отчета.
4) Искать возможность использования других таблиц в которых нужные поля имеют индекс и выборка будет идти быстрее.
5) При необходимости создавать индекс.
6) Иногда эффективней часть вычислений перенести на сервер приложений и вашу программу.
Crystal_Ra wrote:
select * from table.
Delete from Table Where Field_1 <> 'XXX'.
Так ли это?
Решение, как выполнять запрос, будет принимать сервер базы данных. В любом случае, думаю по такому алгоритму он не пойдет. Будет выполнено полное сканирование таблицы по условию.
Промежуточная темповая таблица строрится не всегда, а если в запросе используется объединение двух или нескольких таблиц, группировка, сортировка, DISTINCT и тд.
как работает RANGES как оператор я представляю.
Вопрос в другом , как раз.
запрос не по ключевым полям заставляет Сервер БД создавать индекс на лету... Это долго и накладно... Плохой стиль в общем.
Вопрос почему немцы в своем коде пишут в запросе RANGES по не ключевому полю ?????
Могу предположить что это эквивалентно:
select * from table.
Delete from Table Where Field_1 <> 'XXX'.
Так ли это?
Не совсем. Если поле не ключевое и не входит в индекс, то произойдет полный перебор таблицы на уровне сервера БД.
При написанном Вами куске проги возникают расходы ресурсов на перенос всей таблицы с сервера БД на сервер приложений.
Age: 48 Joined: 25 Jan 2008 Posts: 580 Location: Москва
Posted: Sat May 17, 2008 2:06 pm Post subject:
luka_rus wrote:
Не совсем. Если поле не ключевое и не входит в индекс, то произойдет полный перебор таблицы на уровне сервера БД
Это в случае, если таблица большая.
vga wrote:
Если таблица небольшая или в свойствах ее указана необходимость кеширования на сервере приложений, то можно запросы строить и по неиндексируемым полям. Это не криминально.
Для случая, который указал vga, полный перебор на уровне сервера БД произойдет только один раз - при самом первом обращении к таблице.
При всех остальных обращениях данные будут доставаться из буфера сервера приложений. _________________ С уважением,
Удав.
Тогда давайте конкретно.
таблица EABL объем 28 000 000 записей.
и выборка по не ключевому полю мне кажеся не разумным...
Возможно только вариант запроса с ключевыми параметрами тогда сервер БД оптимизирут выборку по ключу ...
P.S. Вопрос возник после того как я разобрал SAP функцию для получения док. считываня. И там Написаны в выборке по не ключевым полям операторы IN ... что и вызвало подозрение...
Ведь система массового обслуживания должна быть оптимизирована на таком уровне... а здесь потеря времени и ресурсов на лицо Странно как-то. _________________ (SAP) Система нипель... выпускает лучше, чем впускает!
Age: 48 Joined: 25 Jan 2008 Posts: 580 Location: Москва
Posted: Sun May 18, 2008 1:01 pm Post subject:
Ключевые слова "должна быть"
На практике в случае обнаружения таких косяков выставляется сообщение в SAP.
Как пример могу привести историю про плохое быстродействие при сохранении документов DMS(Document Management System) с большим количеством связей со стандарными документами(SD, FI, FM) - таблица DRAD.
При маленьком количестве связей все было нормально, как только количество связей стало превышать 100, документы начали сохраняться очень долго.
Как оказалось, программа SAP при любом изменении документа DMS:
1.Считывала все записи из DRAD для документа DMS.
2.При сохранении удаляла ВСЕ записи из DRAD для документа DMS
3.Вставляла записи из п.1 в таблицу DRAD
При этом никакого изменения связей не происходило, менялись поля в заголовке документа DMS.
После выставления сообщения и предоставления примера SAP через месяц выпустил ноту, которая решила данную проблему _________________ С уважением,
Удав.
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.
как работает RANGES как оператор я представляю.
стиль в общем.
