FOR ALL ENTRIES по сортированной таблице

Parazit

ArmAnn написал:

Parazit написал:

По большей части внутренние таблицы используют из-за плохого понимания SQL (исключая вышеописанные случаи с класт. табл. и т.д.).

Да ладно, с вашим ли опытом быть таким категоричным?

Использование внутренних таблиц позволяет упростить запросы, а значит их проще отлаживать и оптимизировать.
Также нагрузка с сервера БД (который у нас один) переносится на сервера приложений (которых у нас много).
Сам САП так и рекомендует - запросы делать попроще, обработку данных по возможности переносить на сервер приложений - думаете это они с жиру бесятся?

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

Именно опыт и позволяет мне быть таким категоричным.

Однажды (лет 12 назад) мне пришлось решать довольно сложные задачи исключительно при помощи SQL. Поначалу это доставляло серьезные трудности, т.к. я был развращен нестандартными возможностями Foxpro. Но, когда ты поставлен ("зациклен") в жесткие рамки SQL, приходится менять мышление ("на то голова и нужна"). Вот тогда я заценил математический подход SQL, чего и всем советую.
Работа с СУБД вообще не конек SAP, для совместимости ей приходится поддерживать свои "доморощенные" решения, отсюда и рекомендации. Поэтому, по возможности, лучше не использовать её "фичи". Возможности SQL на голову выше возможностей внутренних таблиц, нужно только их понимать. А внутр. таблицы просто расхолаживают, позволяют "прикидывать на пальцах" - типа "я сейчас считаю все во внутр. табличку, а потом с ней разберусь". В действительности такой подход усложняет алгоритм, теряется эффективность, читабельность и модифицируемость.
Для отладки я сначала пишу вложенные SELECT-ы, этого вполне достаточно. Потом оптимизирую и объединяю в JOIN-ы. И уж как последнее средство использую для оптимизации внутр. таблицы.

ArmAnn

Parazit написал:

Именно опыт и позволяет мне быть таким категоричным.

Однажды (лет 12 назад) мне пришлось решать довольно сложные задачи исключительно при помощи SQL. Поначалу это доставляло серьезные трудности, т.к. я был развращен нестандартными возможностями Foxpro. Но, когда ты поставлен ("зациклен") в жесткие рамки SQL, приходится менять мышление ("на то голова и нужна"). Вот тогда я заценил математический подход SQL, чего и всем советую.
Работа с СУБД вообще не конек SAP, для совместимости ей приходится поддерживать свои "доморощенные" решения, отсюда и рекомендации. Поэтому, по возможности, лучше не использовать её "фичи". Возможности SQL на голову выше возможностей внутренних таблиц, нужно только их понимать. А внутр. таблицы просто расхолаживают, позволяют "прикидывать на пальцах" - типа "я сейчас считаю все во внутр. табличку, а потом с ней разберусь". В действительности такой подход усложняет алгоритм, теряется эффективность, читабельность и модифицируемость.
Для отладки я сначала пишу вложенные SELECT-ы, этого вполне достаточно. Потом оптимизирую и объединяю в JOIN-ы. И уж как последнее средство использую для оптимизации внутр. таблицы.

Эти рекомендации САПа не от того что не поддерживаются все фичи SQL, а от того что ресурсы сервера БД дороже и сложнее наращиваются чем ресурсы сервера приложений.
И хотя я тоже довольно много работал исключительно с SQL (T-SQL), и мое мнение насчет 'эффективности, читабельности и модифицируемости' несколько другое

Здесь периодически выкладывают большие запросы с вопросом 'Почему работает не так как хочу', и обычно проще всего такой вопрос решить разбиением запроса на несколько более простых, которые проще отладить отдельно. Также, на мой взгляд, эти отдельные запросы проще оптимизировать, нежели один большой.

Удав

ArmAnn написал:

...
Также нагрузка с сервера БД (который у нас один) переносится на сервера приложений (которых у нас много).
Сам САП так и рекомендует - запросы делать попроще, обработку данных по возможности переносить на сервер приложений - думаете это они с жиру бесятся?

Parazit написал:

Работа с СУБД вообще не конек SAP, для совместимости ей приходится поддерживать свои "доморощенные" решения, отсюда и рекомендации.

+1

Parazit написал:

Поэтому, по возможности, лучше не использовать её "фичи". Возможности SQL на голову выше возможностей внутренних таблиц, нужно только их понимать. А внутр. таблицы просто расхолаживают, позволяют "прикидывать на пальцах" - типа "я сейчас считаю все во внутр. табличку, а потом с ней разберусь". В действительности такой подход усложняет алгоритм, теряется эффективность, читабельность и модифицируемость.

Использование только "чистого" SQL в 3-х звенной архитектуре сделает узким звеном сервер БД.

По этому поводу ArmAnn правильно отметил

ArmAnn написал:

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

Sergo

В ORACLE, например, наряду с SQL есть и PL/SQL. И там такие же вн. таблички используются.

demst

Sergo написал:

В ORACLE, например, наряду с SQL есть и PL/SQL. И там такие же вн. таблички используются.

Внутренних табличек, как в SAP, в оракле нет. Во всяком случае раньше не было. Есть курсоры, которые имеют принципиальное отличие от саповских внутренних табличек.

raaleksandr

demst написал(а):

Внутренних табличек, как в SAP, в оракле нет.

Есть, просто они по-другому называются.
В общем такую конструкцию в PL/SQL можно изобразить один-в-один:

Code:

DATA: lt_itab   TYPE TABLE OF tab1.

SELECT *
  FROM tab1
  INTO TABLE lt_itab
  WHERE field1 = 'VALUE1'.

Но в отличие от SAP в oracle рекомендуют ими пользоваться только в крайних случаях из соображений производительности.
То есть у них это лишь как дополнительная возможность для сложных алгоритмов, а основная - это SQL.
Но это ни в коем случае не доказывает или опровергает что-то по SAP, потому что это совершенно разные системы.

somebody

Parazit,

Цитата:

В идеале нужно обходиться совсем без внутренних таблиц. Например, если ваш отчет фактически должен содержать 3 записи с агрегированными суммами по некой аналитике, то идеальным будет запрос, возвращающий готовый результат. Простейший вариант, использующий SELECT и WRITE вполне удовлетворяет этому требованию.

Попадаются сложные ТЗ, на выходе коих - ALV; если вообще получится в лоб реализовать логику в select'ах, соотношение БД/ABAP будет неприемлемым (огромные таблицы, множество join'ов и группировок), SELECT+WRITE не вариант...

All,
вообще, интересная дискуссия насчёт внутренних таблиц. Мне по девелоперской рассылке пришла ссылка на блог программера из SAP Labs India (опыт работы с ABAP 5 лет) http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/18787, так он особо рад внутренним таблицам:

Цитата:

...I ended up coding a long-winded program in C++, where I could not use internal tables and had to stick to some age-old concept called arrays and vectors.

(жирный шрифт блоггера)
Я бы не стал отметать мнение только потому, что это India, учитывая его опыт работы...

Пономарев Артем

Флудеры

1. Если выборку из БД можно выполнить в рамках одного DML запроса SELECT - в 99% случаев следует поступить имено так.
2. Внутренние таблицы ЯП ABAP - штука полезная и годная к применению.
3. Чувак из индии - ламер.

somebody

Пономарев Артем,

Цитата:

1. Если выборку из БД можно выполнить в рамках одного DML запроса SELECT - в 99% случаев следует поступить имено так.

Опять-таки, как насчёт соотношения времени БД/ABAP? Оно должно быть мало (по возможности). Неплохое объяснение здесь (https://forums.sdn.sap.com/message.jspa?messageID=7409577)

Цитата:

Generally speaking: Looking at a big system we have more application servers but only one database. And we can add resources to application layer by adding applications servers (e.g. on additional physical servers with additional cpus) more easily than adding ressources to DB layer since the db typically runs on only one physical server (there are exceptions). Changing a program in a way that it uses more ABAP time and less DB time results in more resource consumption to the application layer and less resource consumption on the db layer. so the ressource consumption is shiftet to that layer that could be distributed on more physical cpus, generally speaking.

Если велико - ну не примут у меня такую реализацию "в рамках одного запроса".

Цитата:

2. Внутренние таблицы ЯП ABAP - штука полезная и годная к применению.

Вот мне тоже так думается...

Цитата:

3. Чувак из индии - ламер.

Не уверен... Но, видимо, и не гуру.

Пономарев Артем

somebody, есть sdn, а есть суровая правда жизни. Как часто вам приходится писать запросы, которые потребуют сколь-либо заметное количество русурсов СУБД? Даже если приходится, то это тот самый один процент из моего сообщения, стоящий дополительного анализа.
Обатно же, практика показывает, что программы, состоящие из невозбранно большого набора отдельных запросов, работают в целом дольше и при анализе не дают нормального распределения нагрузки между сервером приложений и сервером БД.
Лично я оптимизировал достаточно подобных программ.

P.S.: Про индуса я говорил не основываясь на его знаниях ЯП ABAP и восторгах по поводу внутренних таблиц, а основываясь на том, что в одной процитированной вами фразе товарищ показал свою полную безграмотность в ЯП C++ и его стандартных библиотеках.

Ich Will

Есть статейка про это - Learn How to Avoid Lackluster System Performance When Using the “FOR ALL ENTRIES IN” Clause: An ABAP Developer’s Guide там, насколько я понял после беглого просмотра, пишут что про сортированной таблице он FOR ALL ENTRIES IN быстрее работает.

SYS

Интересно, любители "10-ти этажных SQL запросов" текстовые значения из справочников тоже цепляют в один запрос, или же используют внутренние таблицы как буфер?

Parazit

SYS написал(а):

Интересно, любители "10-ти этажных SQL запросов" текстовые значения из справочников тоже цепляют в один запрос, или же используют внутренние таблицы как буфер?

А чем "текстовые значения из справочников" отличаются от прочих?

SYS

Parazit написал:

А чем "текстовые значения из справочников" отличаются от прочих?

Абсолютно ничем, за исключением скорости выбора данных и количества обращений к БД.

Parazit

SYS написал(а):

Parazit написал:

А чем "текстовые значения из справочников" отличаются от прочих?

Абсолютно ничем, за исключением скорости выбора данных и количества обращений к БД.

В таком случае "10-ти этажный SQL запрос" эффективней по скорости и количеству обращений.

Правила форума

FOR ALL ENTRIES по сортированной таблице

Кто сейчас на конференции