SAP DB больше нет , да здравствует MySQL! ;-)

> Eugene_Korobko (*) (2003-05-28 14:22:46.676)

Согласен полностью :-)
Ну нету места для SAPDB ....

MfG

Konstantin

> Eugene_Korobko (*) (2003-05-28 14:22:46.676)

Ну и вместо Informix нужно писать DB2 :-))

MfG

Konstantin

<цитата> Повторяю. Вот есть такой продукт под gpl - операционная система gnu/linux. По-вашему, тогда получается, что если я поставляю компьютерную технику с предустановленным linux плюс какие-то свои программы, я должен открывать код этих программ? Да ни разу! </цитата>

Не надо повторять. Прочитайте пожалуйста еще раз мой ответ.

Никто от вас не требует коммерческой лицензии, елси вы просто поставляете продукт который использует mysql. Однако если вы распространяете mysql _в_составе_ своего продукта то вы _или_ должны выложить свой продукт под GPL _или_ купить коммерческую лицензию.

Distribute with your non os soft -- распространяте mysql _вместе_ с вашим не os продуктом.

текст лицензии mysql неоднократно обсуждался и согласовывался с FSF. Так что если хотите знать FREE этот софт или нет - не выдергивайте фразы ин контекста, а прочитайте всю лицензию (Ссылки я давал)

<cite> Причём тут шутки? Что такой SQL-сервер? Это такая хрень, которая умеет: - поддерживать SQL (как минимум, на уровне SQL-89) - обеспечивать целостность данных (foreign keys и пр.) - обеспечивать транзакции (хотя бы двух видов уровня изоляии из четырёх, описанных в ISO) Это минимум. <censored/> Вот и получается, что MySQL не дотягивает просто до звания SQL-сервер. </cite>

mysql поддерживет entry level ansi sql 92. открываем спецификацию ANSI SQL92 и смотрим - где там в entry level скажем foreign keys?

Кстати FYI Foreign keys - есть в mysql. И транзакции тоже ( "В терминах описания уровней изоляции транзакций (SQL-1992), InnoDB по умолчанию использует REPEATABLE READ. Начиная с версии 4.0.5, InnoDB предлагает все 4 уровня изоляции описанные в стандарте SQL-1992" ) <cite>А чтобы говорить о "продвинутых возможностях", тут уж не обойтись без поддержки кластеров, управления распределенными транзакциями, поддержки реплиаций и т,д. </cite>

FYI: в mysql есть кластеры (http://www.emicnetworks.com/ к примеру) и есть репликации (это смотрите в докаx на mysql, встроенная фича).

2 walrus:

> Не надо повторять. Прочитайте пожалуйста еще раз мой ответ.

walrus, я в курсе про существование и смысл dual license. Я всего одну вещь не пойму, см. ниже.

> Никто от вас не требует коммерческой лицензии, елси вы просто
> поставляете продукт который использует mysql. Однако если вы
> распространяете mysql _в_составе_ своего продукта

То есть если я закатал на болванку свой продукт и написал "скачайте MySQL" - это можно. А если положил рядом на болванку MySQL - нельзя? А разница?

Мне _действительно_ это интересно, ибо вот этой особенности gpl-лицензии я никогда не понимал. В смысле - нафига? gpl защищает от закрытия _кода_, но причём тут поставка дистрибутива, когда код вообще никто не трогал?

Это же отрицательно влияет на качество софта. Если я оттестировал софт с версией X MySQL, а клиент поставит Y - никаких гарантий давать уже нельзя, это аксиома.

> Ну и вместо Informix нужно писать DB2 :-)) пока нет, слава богу, и еще несколько лет нет, а потом, видимо, ни DB2, ни Informix не будет. Они новый продукт готовят, насколько я знаю.

Вот че седня написала некая Марина Монтаг в сапдбешных мыл листах

Dear SAP DB Community,

Through our partnership with MySQL AB and a MySQL rebranding of SAP DB, we will head to get a bigger share of the DBMS market inside the SAP customer base as well as in the non-SAP market. This will improve both our visibility and our market perception.

MySQL is the most popular open source DBMS. Our partnership combines enterprise-class DBMS technology with the power of the most quickly growing open source community. Together we want to create enough momentum to become the number four in the DBMS market. What Linux is for operating systems today,
we intend to become for database management systems in the future. Our partnership will expedite the growth of the MySQL ecosystem of end users, consultants, DBMS service companies, and independent software vendors.

Starting in Q4 2003, SAP DB will be renamed under a MySQL branding. SAP AG remains responsible for ongoing development and support. So SAP may have given up the DBMS market but has not given up the development of DBMS technology. The rebranded version of SAP DB will be promoted and offered inside
the SAP customer base together with SAP applications as well as outside the SAP market. The rebranded version of SAP DB will be part of MySQL AB's product portfolio in addition to its present product offerings. In this way, the large community of MySQL users gets the alternative of an
enterprise-ready database product. Contrary to erroneous press reports, SAP AG has not given up any rights concerning the SAP DB code base nor handed over or even sold SAP DB to MySQL AB.

The rebranded version of SAP DB will be no longer published under the present licensing model: LGPL for all client libraries and GPL for the rest of the system. Instead, MySQL AB will offer the rebranded SAP DB under their proven business model. It will be available as open source software
completely under GPL as well as under a commercial license at commodity prices. This will be the only real change for the present SAP DB user community.


Best regards,

Your SAP DB Team

_______________________________________________
sapdb.announce mailing list
sapdb.announce@listserv.sap.com
http://listserv.sap.com/mailman/listinfo/sapdb.announce
_______________________________________________
sapdb.announce mailing list
sapdb.announce@listserv.sap.com
http://listserv.sap.com/mailman/listinfo/sapdb.announce


Понимайте как хотите ;-)

можно того анонимного инсайдера IBM спросить поподробнее что за продукт готовит IBM и где про это можно почитать?

Специально для Kondrat:

> Вы действительно думаете, что самое главное в ERP
> системе,которой и является SAP/R3, это редактор для
> программиста?

Упаси господь. Я как раз и привел пример относительно несложного
инструмента, который, тем не менее, реализован отвратно плохо.
Возникают подозрения, что основные функции также могут быть
реализованы некачественно.

> Какие конкретные претензии к редактору в версии 4.6?

Все те же. Ограничение длины строки. Ну да она не обрывается, а
переносится. Но выглядит это ужасно. Трудно написать удобоваримое
руководство, скажем, по использованию отступов в исходных текстах для
кодеров. Неэкономный визуальный дизайн интерфейса. С ним совершенно
невозможно работать на 15" мониторе. В то же время на семнашке и
девятнашке большая часть экрана пустует из-за ограничения длины
строки. Отсутствие подсветки синтаксиса. Отсутствие автодополнения.
(в каком веке живем?)

> Приведите, пожалуйста, примеры: часто ли в этих
> "некоторых вещах" возникает необходимость в повседневной
> работе и много ли приходится при этом писать кода?

Часто и много. При разработке формуляров, например. Ни один из
стандартного комплекта нам не подошел. Пришлось разрабатывать
самостоятельно. И меняются они достаточно часто. Про WYSIWYG-редактор
лучше не упоминайте. Представление документа в нем абсолютно не
соответствует тому, что получается на бумаге или на экране при
предварительном просмотре. Оформление того, что казалось бы уже
сделано и работает, часто съезжает при использовании
WYSIWYG-редактора. Так что в данном случае альтернативы Line Editor
нет. И писать приходится много. Наши документы это не фактурв с
накладной. Все гораздо сложнеее.

> Интересно. Пройдитесь подробно, только,
> пожалуйста без накала страстей и развешивания ярлыков типа
> "технологический дебилизм", а с конкретными фактами и
> примерами.

Это уже завтра. Мне работать надо. С фактами и примерами.
С эмоциями и ярлыками. Если вещь выглядит как дерьмо и пахнет как
дерьмо, то я и назову ее дерьмом. Извините.

анонимный инсайдер как бы сам от инсайдеров слышал, причем даже не очень вчера. поищи старых дистрибуторов информикса, да порасспроси их - где-то с год назад такая информация и была. там ведь суть покупки была в том, что вся команда разработчиков информикса тоже ушла в ibm. а вообще вот:

IBM is building the next-generation relational database that both Informix and IBM have been on a path towards for several years. The best of IDS, XPS, Red Brick, and "classic" servers will add to the technology in DB2 Information Management Software -- creating the vision that Informix had called "Arrowhead." It's all part of the IBM commitment to providing solutions for next-generation e-business through our information on demand initiative.

ну и вот:

http://www.iiug.org/news/don_ltr.html

> То есть если я закатал на болванку свой продукт и написал "скачайте > MySQL" - это можно. А если положил рядом на болванку MySQL - нельзя? > А разница?

> Мне _действительно_ это интересно, ибо вот этой особенности > gpl-лицензии я никогда не понимал. В смысле - нафига? gpl защищает от > закрытия _кода_, но причём тут поставка дистрибутива, когда код > вообще никто не трогал?

На болванку класть очень даже можно. Но только вместе с исходниками и лицензией (или указать URL исходников).

2 Rock:

> На болванку класть очень даже можно. Но только вместе с исходниками
> и лицензией (или указать URL исходников).

Ха. Вот Вы говорите, что можно. А MySQL AB говорит, что нельзя (цитаты выше приводил я, ссылки - walrus).

И как енто всё вместе понимать? ;-)

> Упаси господь. Я как раз и привел пример относительно несложного
> инструмента, который, тем не менее, реализован отвратно плохо.

Инструмент в версии 4.6 реализован хорошо. В более старших версиях -
удовлетворительно. Кстати, насколько я помню, в 4.0 можно было задать внешний редактор, если на встроенный идиосинкразия. Правда тогда
перестают работать drill down-ы, так что все знакомые мне программисты в итоге вернулись к LINE EDITOR-у.

> Возникают подозрения, что основные функции также могут быть
> реализованы некачественно.

Вообще-то, следуя здравому смыслу, при разработке любой сложной системы, в том числе и ERP, следует в первую очередь сконцентрировать усилия на основных функциях, на то они и основные, и только потом, на второстепенных. Поэтому делать выводы о качестве реализации ОСНОВНЫХ ФУНКЦИЙ на основе субъективной оценки качества одной второстепенной функции - не корректно.


> Все те же. Ограничение длины строки. Ну да она не обрывается, а
> переносится. Но выглядит это ужасно.

Не понимаю что там ужасного? Все выглядит, как в обычном редактроре в котором установлен автоперенос строки и длина строки 72 символа.

> Трудно написать удобоваримое
> руководство, скажем, по использованию отступов в исходных текстах
> для кодеров.

Наоборот, легко. В таком руководстве должно быть всего три слова:
используйте PRETTY PRINTER :) Мне его хватает за глаза и очень напрягает отсутствие такой полезнейшей фичи, в других редакторах, когда приходится писать, например, на PERL-е.


> Неэкономный визуальный дизайн интерфейса. С ним совершенно
> невозможно работать на 15" мониторе. В то же время на семнашке и
> девятнашке большая часть экрана пустует из-за ограничения длины
> строки.

Вы на какой версии R3 работаете? 4.0? В 4.6 ничего подобного не наблюдаю, а 4.0 уже подзабыл немного за 2 года, но все-равно
таких негативных эмций не было.

Работал полтора года на 15"(1024х768) в 4.0 - абсолютно никаких неудобств не испытывал. Сейчас уже 2 года на 17" в таком же разрешении в 4.6 - тоже никаких проблем. В редакторе всегда включен "Просмотр списка объектов" и все на экране отлично помещается. В общем - очень субъективно все это.

> Отсутствие подсветки синтаксиса. Отсутствие автодополнения.
> (в каком веке живем?)


Вместо подсветки синтаксиса я использую опцию PRETTY PRINTER-а большое ключевое слово - результат примерно тот же, а пестрота на экране не раздражает. А вот автодополнения действительно нет, но это, IMHO, особенность самой идеологии R3 - минимизация обращений к Application Server-у.

Если действительно жизнь без автоподсветки и автодополнения кажется каторгой - купите внешний редактор от сторонних разработчиков. Там все это есть.


> Часто и много. При разработке формуляров, например. Ни один из
> стандартного комплекта нам не подошел.

В версии 4.6 при разработке формуляров можно переключиться из LINE EDITOR-а в нормальный редактор. Только что посмторел и убедился.

> Так что в данном случае альтернативы Line Editor
> нет.

Так что альтернатива - есть.

> И писать приходится много. Наши документы это не фактурв с
> накладной. Все гораздо сложнеее.

Если писать приходится много, причем сложных документов, то есть смысл рассмотреть использование альтернативных формулярам технологий.
Например SMART FORMS и бизнес-документы. У нас на проекте с формулярами приходится иметь дело только при исправлении косяков сторонних разработчиков. Все собственные разработки делали на альтернативных технологиях.


> Это уже завтра. Мне работать надо. С фактами и примерами.
> С эмоциями и ярлыками. Если вещь выглядит как дерьмо и пахнет как
> дерьмо, то я и назову ее дерьмом. Извините.

Эта вещь не выглядит как дерьмо и не пахнет как дерьмо, поэтому ее не стоит называть дерьмом.

Так что, жду дальнейших фактов и примеров.

Kondrat.

а что такое формуляры? объясните человеку, незнакомому с русской терминологией sap r/3 :)

значит всё работает и все тащацца, говорите?

определяете две внутренние таблицы, в screen painter рисуете их рядом друг с другом на одном уровне. тестируете - работает

опускаете вторую таблицу на строку или две ниже. тестируете и медленно охуеваете - не показывает содержимое обеих таблиц

2 Kondrat:

"Вообще-то, следуя здравому смыслу, при разработке любой сложной системы, в том числе и ERP, следует в первую очередь сконцентрировать усилия на основных функциях, на то они и основные, и только потом, на второстепенных. Поэтому делать выводы о качестве реализации ОСНОВНЫХ ФУНКЦИЙ на основе субъективной оценки качества одной второстепенной функции - не корректно."

Но R/3 это же не коробочное решение. Там много нужно настраивать и зачастую дописывать. Так что редактирование программ в этой ситуации является побочной функцией системы, но никак не второстепенной. То же самое можно сказать и о выборе языка программирования для такой системы. Он не должен мешать разработке. А что мы имеем в случае ABAP/4?

Итак, комментарии. Блочных комментариев в системе нет. Есть только строчные. Причем 2 видов. Если комментарий начинается с 1-го символа строки, то нужно использовать звездочку (*), а если нет (не с первого символа), то двойную кавычку ("). Почему так? А хрен его знает. Но это так для разминки.

Далее выражения. Выражения это песня. Как вы думаете, что неправильно в логическом выражении l_curr_charg<>ls_charg_lifnr-charg. Хрен догадаетесь. Пропущены пробелы между операндами и знаком операции. Правильно будет вот так: l_curr_charg <> ls_charg_lifnr-charg. Кстати о птичках, знаете, что неправильно в выражении l_curr_charg <> ls_charg_lifnr-charg + 1? Вот Kondrat должен знать. Операндами выражения не могут быть другие выражения. Я сначала должен запихнуть ls_charg_lifnr-charg + 1 в переменную и только потом сравнивать значение этой переменной с l_curr_charg. Точно также нельзя использовать выражение как фактический параметр при вызове процедуры. Круто, правда? Я долго вспоминал какой другой язык программирования с такими ограничениями, так и не вспомнил. Молодой наверно. Заметили, кстати, что имена у переменных неговорящие? А они в SAP-овских программах все такие. Имена таблиц - 4 символа, имена столбцов и переменных - символов. Давай, Kondrat, скажи-ка нам, для чего используются таблицы STXH, BKPF, BSID, BSIK, MBEW, MCH1, VBFA, VBRK. Только в SE11 чур не подглядывать.

Далее, структурное программирование. Ну все операторы ветвления и цикл while с предусловием в языке есть. Так что все в порядке, если не вспоминать про ограничения выражений. А что с подпрограммами? Их есть у нас. То есть у них. Целых 2 вида. Думаете, это по смыслу процедура и функция? Очень интересно заблуждаетесь. Обе процедуры и плевать, что один вид гордо именуется функциональным модулем. Функциональный модуль считается более современной вещью. Они для работы с ними отдельную транзакцию сделали. Вот только вызываются они исключительно динамически. Если я скажем в названии модуля опечатку сделал, то узнаю об этом только на стадии тестового прогона программы. С именами параметров еще хуже. Та же опечатка не вызывает никакой ошибки (в точке вызова). Просто фактический параметр не попадает в процедуру и все.

Функций у них нет вообще. Пользовательских. Есть весьма ограниченный набор встроенных функций, которые, вот радость, можно использовать в выражениях. Но функции округления, например, нет. Что, Kondrat, не нужна она? Или написать легко? Да уж написали мы округление, не волнуйся. Вот только в функцию не можем никак запихнуть.

Объектно-ориентированное программирование. Есть. Синтаксис вызова метода объекта отличается от вызовов других процедур. Другие люди уже дописали, очевидно. То есть если я знаю, что такое ООП и знаю, как работать с процедурами на ABAP, то это мне никак не поможет. Все равно придется серьезно доки читать.

Не знаю, стоит ли еще про OpenSQL писать. Я и так уже тут наколбасил достаточно, чтобы понять, что нет в ABAP/4 ни строгого дизайна, как у Паскаля, ни "лингвистической легкости" как у Perl, ни компактности конструкций как у C, ни простоты, как у Python. Вы уж извините, Kondrat, но это дерьмо. ИМХО.

ну могу подписаться под словами Чикаго

Так я не понял- вы тут про R/3 или про SAP DB? :-)
По поводу SAP DB - такой поступок SAP, как решение прикончить SAP DB, imho, чести SAP не делает.
За более чем 2 года SAP так и не сделала, да и не хотела делать SAP DB open source. Нет, исходники то есть, а вот реальных разработчиков не из SAP так и не появилось. Они это называали open source вместо marketing в своем тукаменте, опубликованном на sapdb.org. Как видим, ниче их этого не вышло, не стали кустомеры на SAP DB ломиться, да оно и понятно- так как кроме % при покупке решений SAP R/3 за RDBMS ( например, за Oracle-
+11% к лицензии R/3, за SAP DB= 0%), за саппорт оного решения надо платить 17% в год от стоимости лицензии. И тут то (сюрприз!) оказывается, что стоимость суппорта для SAP DB считается так, как будто оно стоит то ли 5 то ли 6% от стоимости R/3. Вот так закончилась попытка
SAP показать Oracle, что они Oracle на хую вертели ;-)

Аналогичная картина, кстати сказать наблюдается и отношении Linux.
Сначала все выглядело пристойно- все работало на RH 6.x, свободно скачанном или еще где взятом. А щас только на SLESx, RH AS по _ПОЛИТИЧЕСКИМ_ соображениям не сертифицируют. Ну да, опять же, сей выпад против MS закончился ничем, кустомеры покупают рытри по винду.
Скоро, я уверен, SAP попытается прекратить поддержку Linux.

> а что такое формуляры? объясните человеку, незнакомому с русской
> терминологией sap r/3 :)

SAP Scripts

> значит всё работает и все тащацца, говорите?

Где я такое говорил? Может цитату приведете?

> определяете две внутренние таблицы, в screen painter рисуете их
> рядом друг с другом на одном уровне. тестируете - работает

Это радует.

> опускаете вторую таблицу на строку или две ниже. тестируете и
> медленно охуеваете - не показывает содержимое обеих таблиц

Т.е. в Srceen pinter-е GRID перемещаете на две строки ниже и перестает работать? И в коде ничего не меняли? Очень похоже на сказки Венского леса.

Может мне транспорт этой чудесной транзакии вышлите? Хочу тоже на чудеса посмотреть. Ни разу еще не видел, чтоб от передвижения элементов на экране таранзакция правильно работать перестала.

Kondrat

> Но R/3 это же не коробочное решение. Там много нужно настраивать и
> зачастую дописывать. Так что редактирование программ в этой
> ситуации является побочной функцией системы, но никак не
> второстепенной.

Основная фукциональность при правильной разработке должа достигаться за счет настроек и оптимизации бизнес процессов, а не за счет программирования. Настройки должны быть первичны, они - основной инструмент.

Кстати, вы так и не высказали обоснованных возражений на мой комментарий о редакторе программ в 4.6, значит к редактору претензий больше нет?

> То же самое можно сказать и о выборе языка
> программирования для такой системы. Он не должен мешать разработке.

Он и не мешает.

> А что мы имеем в случае ABAP/4?

И что же мы имеем?

> Итак, комментарии. Блочных комментариев в системе нет. Есть только
> строчные. Причем 2 видов. Если комментарий начинается с 1-го
> символа строки, то нужно использовать звездочку (*), а если нет (не
> с первого символа), то двойную кавычку ("). Почему так? А хрен его
> знает. Но это так для разминки.

Для разминки предлагаю подумать зачем нужны блочные комментарии, и как это реализовано в ABAP редакторе, вместо того, чтоб думать, "Почему так?". Такой подход ГОРАЗДО более полезен и конструктивен.

Комментарии нужны для закомментирования блоков текста. Как это реализовано в редакторе? Выделяете блок текста, который нужно закомментировать, и нажимаете комбинацию клавиш Ctrl + < Все, блок закомментирован. Это, по-вашему, не удобно?


> Заметили, кстати, что имена у переменных неговорящие? А они в SAP-
> овских программах все такие.

Ну, во-первых, не все, и не во-всех программах. Кстати, имена переменным обычно дают программисты, а не язык программирования.
Объясните мне, пожалуйста, как эта претензия относится именно к
ABAP-у? В нем ограничение на длину имени переменной намного больше
5-ти символов.

> Имена таблиц - 4 символа, имена
> столбцов и переменных - символов.
> Давай, Kondrat, скажи-ка нам, для
> чего используются таблицы STXH, BKPF, BSID, BSIK, MBEW, MCH1, VBFA,
> VBRK. Только в SE11 чур не подглядывать.

Отвечу именно на это и именно в воскресенье из дома, чтоб не было соблазна в SE11 подглядывать :)

STXH - заголовки текстов в SAP Script
BKPF - заголовки бухгалтерских документов
BSID - бухгалтерские документы по дебеторам
BSIK - бухгалтерские документы по кредиторам
MBEW - основные данные материала, бухгалтерский ракурс(классы оценки)
VBFA - поток документов сбыта
VBRK - заголовки сбытовых фактур
MCH1 - не знаю

Опять не понимаю что тут ставится в вину языку программирования? Неужели вы свои таблицы не можете называть как вам хочется?
Опять же ограничения на длину имене таблицы и имени поля намного больше 4-х и 5-ти символов.

А запомнить четырехбуквенные имена таблиц легче, чем кажется на первый взгляд. Многие - вполне разумные. Возьмем, например,
BSID - это аббревиатура BSEG Secondary Index for Debetors.

На остальное отвечу завтра.

Предыдущее сообщение - мое.

Kondrat.

Кстати, щас в списке рассылки SAP DB его счастливые пользователи возят мордой по столу "коммунального адвоката MySQL" Zak'а Greant'а. Вот типичный образчик: http://listserv.sap.com/pipermail/sapdb.general/2003-May/021229.html

Всем очень рекомендую для поднятия настроения:

I won't say anything about the likelihood of "future success". But there's one thing that I don't remember having been said here yet. We're all worried that the reputation of SAP DB will deteriorate as soon as the word "MySQL" appears within a hundred meters of it. Could it be that MySQL AB is expecting that the name "SAP DB" will improve MySQL's reputation?

Прочитал. Я бы сказал наоборот. Zak отвечает очень корректно и ведет себя "по взрослому". В отличие от его оппонентов, которые разводят LOR-подобный флейм. Видимо предыдущего анонимнуса это и привлекло - что-то знакомое увидел в высказываениях в этой рассылке - то же неуважение к собеседникам, ту же привычку не слушать доводов...

walrus (*) (2003-06-01 11:07:59.079833):

> Zak отвечает очень корректно и ведет себя "по взрослому".

Zak не _отвечает_, а _отмазывается_. Ни на один из серьёзных вопросов:

1) Что будет с клиентскими библиотеками, которые сейчас под LGPL?

2) Как будет интегрироваться SAP DB? Как storage engine (дурацкая затея, т.к. фичей в том же SQL SAP DB понимает поболее, чем MySQL) или как-то по-другому?

он так и не ответил, и полное впечатление что не может ответить, т.к. не рубит фишку.

Вот кстати, интересный взгляд на вещи, который _хорошо_ объясняет происходящее шуршание: http://listserv.sap.com/pipermail/sapdb.general/2003-June/021253.html

mySQL isn't assimilating SAPDB. They are getting it for free. I doubt they even know what they have yet.

Do you really think the tiny little mySQL organization "bought out" SAPDB :0 SAP is a huge company with huge profits compared to mySQL.

...

I think the "open sourcing" of SAPDB was a _last ditch effort_ for a product dying from own weight. I think management at SAP decided open sourcing didn't work and is exiting the stage on the DB market. MySQL picked it up at clearance price. I wouldn't be surprised if mySQL is getting free labor (paid employees for x years) and all the technology out of the deal. In other words, SAP may be _paying_ mySQL to take the product as part of a graceful way of ridding themselves of the product.

чего волнуетесь то? такая большая компания как Sap не может себе позволить кинуть клиентов (слишком их много) ради них вон и ABAP до сих пор тянут, и имена 4-х буквенные, и ограничения на длину строк (читайте маразматические споры выше).. насколько я понял, процесс перехода займёт несколько лет, и пока не убедятся, что у всех клиентов всё работает, и как минимум не медленнее чем раньше, ничего трогать не будут.. от договорённости до внедрения ой как долго..

2 Kondrat:

Ну если вам все нравится, то я искренне рад за вас. Вы нашли себя, с чем я вас и поздравляю. В конце концов все впечатления субъективны. После PL/1 и COBOL такой язык как ABAP/4 может даже показаться чем-то суперклассным. Но я останусь при своем мнении. Только не говорите мне, что я в нем одинок :))) И если я и работаю с R/3 то только за деньги. Это единственное достоинство системы. При внедрении и после оного зарплаты проектной группы сразу увеличиваются в 2-3 раза. И дальше больше :-)

"чего волнуетесь то? такая большая компания как Sap не может себе позволить кинуть клиентов (слишком их много) ради них вон и ABAP до сих пор тянут, и имена 4-х буквенные, и ограничения на длину строк (читайте маразматические споры выше).. насколько я понял, процесс перехода займёт несколько лет, и пока не убедятся, что у всех клиентов всё работает, и как минимум не медленнее чем раньше, ничего трогать не будут.. от договорённости до внедрения ой как долго.."

Позвольте прокомментировать. Самых крупных клиентов они действительно не могут позволить себе кинуть. А тех кто помельче - то есть как раз контингент MySQL - легко. Мягко так кинут, вы и незаметите. И ABAP они не ради других тянут, а ради себя. Их код на ABAP в системе преобладает. И переписать все сразу не получится. Другим же они Java обещают уже который год, но результата пока не видели. Что же касается обслуживания новой СУБД, то как раз это они сделают очень быстро. Их методика общения Application Server и SQL Server достаточно примитивна. Это сделано как раз для обеспечения совместимости с зоопарком СУБД, поддерживаемых SAP R/3. И тестировать они будут прежде всего интероперабельность, а не быстродействие.

> Далее выражения. Выражения это песня. Как вы думаете, что
> неправильно в логическом выражении l_curr_charg<>ls_charg_lifnr-
> charg. Хрен догадаетесь. Пропущены пробелы между операндами и
> знаком операции. Правильно будет вот так: l_curr_charg <>
> ls_charg_lifnr-charg.

Догадаться несложно, если знать синтаксис. У каждого языка, он свой,
у каждого - имеет свои особенности, и к любому можно придраться.
Вспомните оператор присваивания том же паскале - можно долго
возмущаться почему он такой. Или необходимость выделять структурные блоки в питоне отступами.

> Кстати о птичках, знаете, что неправильно в
> выражении l_curr_charg <> ls_charg_lifnr-charg + 1? Вот Kondrat
> должен знать. Операндами выражения не могут быть другие выражения.
> Я сначала должен запихнуть ls_charg_lifnr-charg + 1 в переменную и
> только потом сравнивать значение этой переменной с l_curr_charg.
> Точно также нельзя использовать выражение как фактический параметр
> при вызове процедуры.

Это, пожалй, единственный минус ABAP, который вы упомянули более-
менее по-делу. Да и то, в некоторых случаях он превращается в плюс.

> Круто, правда?

Я не оперирую понятиями круто, отстой, рулез - спор с их применением превращается в ругань.

> Я долго вспоминал какой другой
> язык программирования с такими ограничениями, так и не вспомнил.
> Молодой наверно.

Читал где-то, что ABAP - коболоподобный язык.

> Далее, структурное программирование. Ну все операторы ветвления и
> цикл while с предусловием в языке есть. Так что все в порядке, если
> не вспоминать про ограничения выражений. А что с подпрограммами? Их
> есть у нас. То есть у них. Целых 2 вида. Думаете, это по смыслу
> процедура и функция? Очень интересно заблуждаетесь. Обе процедуры и
> плевать, что один вид гордо именуется функциональным модулем.

В названии "Функциональный модуль" главное слово - модуль :)
Примерный аналог в Паскале - модули.

> Функциональный модуль считается более современной вещью. Они для

Кем считается?

> работы с ними отдельную транзакцию сделали. Вот только вызываются
> они исключительно динамически. Если я скажем в названии модуля
> опечатку сделал, то узнаю об этом только на стадии тестового
> прогона программы. С именами параметров еще хуже. Та же опечатка не
> вызывает никакой ошибки (в точке вызова). Просто фактический
> параметр не попадает в процедуру и все.

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

А чтобы не мучиться с именами параметров используйте паттерны - рекомендую.


> Функций у них нет вообще. Пользовательских. Есть весьма
> ограниченный набор встроенных функций, которые, вот радость, можно
> использовать в выражениях. Но функции округления, например, нет.
> Что, Kondrat, не нужна она?

Нужна, но не стоит очертя голову кидаться ее писать самому :)
Например, когда мне понадобилось пересчитывать количество материала из альтернативных едениц измерения к базисной, я просто потратил пол-часа и нашел готовый саповский функциональный модуль, в котором можно было выбрать любое округление на свой вкус, хоть всегда в большую сторону, хоть, всегда в меньшую, хоть по математическим правилам.

> Или написать легко? Да уж написали мы
> округление, не волнуйся. Вот только в функцию не можем никак
> запихнуть.

Да я, в отличие от тебя, не волнуюсь.

> Объектно-ориентированное программирование. Есть. Синтаксис вызова
> метода объекта отличается от вызовов других процедур. Другие люди
> уже дописали, очевидно. То есть если я знаю, что такое ООП и знаю,
> как работать с процедурами на ABAP, то это мне никак не поможет.

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

> Все равно придется серьезно доки читать.

Доки невредно читать в любом случае - экономит огромное количество усилий, времени и нервов в дальнейшем.

> Не знаю, стоит ли еще про OpenSQL писать. Я и так уже тут

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

> наколбасил достаточно, чтобы понять, что нет в ABAP/4 ни строгого
> дизайна, как у Паскаля, ни "лингвистической легкости" как у Perl,
> ни компактности конструкций как у C, ни простоты, как у Python. Вы
> уж извините, Kondrat, но это дерьмо. ИМХО.

Из того, что вы "наколбасили", можно понять, что ни в абапе, ни, тем более, в остальных инструментах разработчика в R3, вы не смогли или не захотели разобраться. Такое впечатление, что вас буквально вынудили всем этим заниматься.

Сравнивать же ABAP - узкоспециалезированный язык для разработки бизнес приложений с языками достаточно универсального назначения типа C, Паскаля или Питона, МЯГКО ГОВОРЯ, не профессионально.

Kondrat.

2 Kondrat:

Улыбайтесь, это раздражает :)))

"Догадаться несложно, если знать синтаксис. У каждого языка, он свой, у каждого - имеет свои особенности, и к любому можно придраться. Вспомните оператор присваивания том же паскале - можно долго возмущаться почему он такой. Или необходимость выделять структурные блоки в питоне отступами."

Не катит как пример. Двоеточие - достаточно заметный глиф. Его не пропустишь так легко как пробел. Да и пропустишь, так и что? Все известные мне компиляторы Паскаль выдают в этом случае весьма разумное сообщение об ошибке. А отступы в Питоне вообще не проблема, autoindent и все. Для того же Vim есть отличные скрипты как раз для Python'a, обеспечивающие удобную навигацию по исходным текстам. Python - красивый язык. Понятием "красивый" вы то же не оперируете? Во что там спор превращается? В ругань? А я грешным делом считал, что спор это и есть ругань. Для определения конструктивного диалога другие слова имеются.:)

"Нужна, но не стоит очертя голову кидаться ее писать самому :)"

То, что мы кидаемся что-то писать, не поискав предварительно готового решения, является вашими домыслами. Оставьте их при себе.

"Это, пожалй, единственный минус ABAP, который вы упомянули более- менее по-делу. Да и то, в некоторых случаях он превращается в плюс."

Пример такого случая, пожалуйста. А то понятиями круто и рулез не оперируете и, кажется, вообще ничем не оперируете. Я вам говорю, что меня особенность X продукта Y раздражает, а вы как эхо: "Не раздражает". Я понимаю, что вы флегматик редкостный, но меня то все равно та вещь раздражает.

"Ну отчего же, напишите. Может вы в хотя бы с ним [OpenSQL] разобрались не так поверхностно, как с абапом, тогда, глядишь, и я что-нибудь конструктивное из нашей беседы почерпну."

По прежнему не уверен, стоит ли. Я намного лучше, чем OpenSQL/ABAP, владею T-SQL и PL/SQL и мне кажется, что если вы ими не владеете на таком же уровне, как я, то вы просто не поймете, что я хочу сказать. (Ну, может, владеете, я этого просто не знаю, а предполагать не хочу).

А, да! Ничего конструктивного вы от меня не дождетесь. Неужели вы думаете, что я собираюсь как то влиять на взгляды сложившегося специалиста? Да это невозможно. А я невозможные задачи не решаю.

"Да я, в отличие от тебя, не волнуюсь."

Опять домысел. Будешь смеяться, я совершенно не волнуюсь. У меня стиль изложения такой. Экспрессивный очень. При этом я редко испытываю эмоции, которые описываю :)))

"В названии "Функциональный модуль" главное слово - модуль :) Примерный аналог в Паскале - модули."

Ну ты сам то понял, что ляпнул? В Паскалевском модуле есть открытая интерфейсная часть и закрытый блок реализации. Каждый может содержать определения\объявления нескольких, а не одного объекта. Естественно, что доступ к закрытой части имеется только в самом модуле. Именно это делает его модулем. И что похожего есть в функциональном модуле?

"... принудили ..."

Молодец! Умный мальчик!!!

"Сравнивать же ABAP - узкоспециалезированный язык для разработки бизнес приложений с языками достаточно универсального назначения типа C, Паскаля или Питона, МЯГКО ГОВОРЯ, не профессионально."

Блин! SAPовских буклетов что ли обчитался? В чем, позвольте спросить, выражается его бизнес-специализированность? Поподробнее, пожалуйста. Мне он представляется обычным языком программирования с Embeded SQL. Все. И некорректным сравнение будет только тогда, когда я начну требовать от ABAP ну, скажем, поддержки регулярных выражений как в Python и Perl. Я этого не требую. Все что я хочу, чтобы мне, лично мне было легко и приятно программировать. У вас понятия об удобстве другие. Ну и флаг вам в руки.

Извините, что долго не отвечал - работы много навалилось :(

> Не катит как пример. Двоеточие - достаточно заметный глиф. Его не
> пропустишь так легко как пробел. Да и пропустишь, так и что? Все
> известные мне компиляторы Паскаль выдают в этом случае весьма
> разумное сообщение об ошибке.

Вот, наконец то добрались до единственного бесспорного недостатка - слабого синтаксического анализатора. Тут спорить не о чем, остается только смириться :)

> А отступы в Питоне вообще не
> проблема, autoindent и все.
> Для того же Vim есть отличные скрипты
> как раз для Python'a, обеспечивающие удобную навигацию по исходным
> текстам.

А чем не устраивает, или кажется неудобной навигация в редакторе ABAP?

> Python - красивый язык. Понятием "красивый" вы то же не
> оперируете?

Ну отчего же - оперирую иногда :)
Просто у всех понятия о красоте разные, поэтому спорить именно о красоте считаю нецелесообразным. Особенно, когда это касается красоты рабочих инструментов - тут все таки другие критерии имеют большее значение.

Python, конечно, красивый язык, но Ruby, по-моему, красивее. Зато в Python, насколько я успел разобраться, стандартная библиотека богаче, поэтому его применение мне кажется более целесообразным.

> Во что там спор превращается? В ругань? А я грешным
> делом считал, что спор это и есть ругань. Для определения
> конструктивного диалога другие слова имеются.:)

Ругань - это разговор без логических аргументов и, вдобавок, переходящий на личности.

> То, что мы кидаемся что-то писать, не поискав предварительно
> готового решения, является вашими домыслами. Оставьте их при себе.

Это не домыслы, это логические выводы из ваших же слов:

> Но функции округления, например, нет.
> Что, Kondrat, не нужна она? Или написать легко? Да уж написали мы
> округление, не волнуйся. Вот только в функцию не можем никак
> запихнуть.

Функции округления - есть, но вы, предпочли написать свою.
Разумную причину писать свое, вместо того, чтобы использовать готовое, я могу представить только одну: готовая по каким-либо причинам не устраивает. Вы же пишите не "не устроила готовая функция округления", а "функции округления, например, нет".

> Пример такого случая, пожалуйста.

Пожалуйста.
Если один и тот же вычисляемый операнд надо использовать не в одном, а в нескольких операторах сравнения. Писанины будет меньше.

> А то понятиями круто и рулез не
> оперируете и, кажется, вообще ничем не оперируете.

Я оперирую фактами. Понятия круто и рулез - не аргументы в споре.

> Я вам говорю,
> что меня особенность X продукта Y раздражает, а вы как эхо: "Не
> раздражает". Я понимаю, что вы флегматик редкостный, но меня то все
> равно та вещь раздражает.

Нет, не так. Наш диалог проходит следующим образом:

Вы - Меня раздражает LINE EDITOR
Я - Пользуйтесь нормальным редактором
Вы - Нормальный редактор недоступен в SAP Script
Я - Доступен, просто вы не разобрались как его включить.

И т.д. в том же духе.

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

> По прежнему не уверен, стоит ли. Я намного лучше, чем OpenSQL/ABAP,
> владею T-SQL и PL/SQL и мне кажется, что если вы ими не владеете на
> таком же уровне, как я, то вы просто не поймете, что я хочу
> сказать. (Ну, может, владеете, я этого просто не знаю, а
> предполагать не хочу).

Про T-SQL не знаю, а вот PL/SQL знаю очень неплохо, так что смело пишите, я все пойму.

> А, да! Ничего конструктивного вы от меня не дождетесь. Неужели вы
> думаете, что я собираюсь как то влиять на взгляды сложившегося
> специалиста? Да это невозможно. А я невозможные задачи не решаю.

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

1) Влияющий сам должен быть тоже специалистом в этой же области, иначе, согласитесь, он просто не сможет понять оппонента.

2) Влияющий должен привести логически обоснованные доводы. Круто, рулез, отстой и т.п. - это не доводы в профессиональной дискуссии.

> "В названии "Функциональный модуль" главное слово - модуль :)
> Примерный аналог в Паскале - модули."

> Ну ты сам то понял, что ляпнул? В Паскалевском модуле есть открытая
> интерфейсная часть и закрытый блок реализации.
> Каждый может
> содержать определения\объявления нескольких, а не одного объекта.
> Естественно, что доступ к закрытой части имеется только в самом
> модуле. Именно это делает его модулем. И что похожего есть в
> функциональном модуле?

В R3 - аналогично. Надеюсь вы учитываете, что каждый функциональный модуль принадлежит группе цункций? И что в любой группе функций можно использовать TYPE-POOL?
И чем тогда подобная конструкция принципиально отличается от паскалевского модуля, кроме синтаксиса?

> "... принудили ..."

> Молодец! Умный мальчик!!!

Сынок, я рад, что ты меня оценил!!!

> Блин! SAPовских буклетов что ли обчитался?

Уж не хамите ли вы мне?
Может приведете примеры буклетов, в которых это написано? Я бы их почитал для повышения общей эрудиции.

> В чем, позвольте спросить, выражается его бизнес-
> специализированность? Поподробнее, пожалуйста. Мне он
> представляется обычным языком программирования с Embeded SQL. Все.

Ну, кроме Embeded SQL, есть еще много чего, например, встроенная поддержка проверки полномочий доступа, логичиские базы данных, поддрежка типов CURRENCY и UNIT, наличие оператов типа COLLECT, HIDE,AT NEW, AT LAST, AT END, INFOTYPE, PROVIDE и т.п.

> И некорректным сравнение будет только тогда, когда я начну
> требовать от ABAP ну, скажем, поддержки регулярных выражений как в
> Python и Perl. Я этого не требую. Все что я хочу, чтобы мне, лично
> мне было легко и приятно программировать. У вас понятия об удобстве
> другие. Ну и флаг вам в руки.

Я бы не стал с вам дискутировать, если бы вы начали именно с этого.
Но вы, не зная толком даже встроенного языка и возможностей редактора, основываясь только на собственных ощущениях, 6ольшинство которых возникло именно из-за этого незнания, позволили себе делать глобальные выводы о всей системе R/3. Это - некорректно.

Предыдущее сообщение - мое.

Kondrat.