|
26.11.2009, 17:45 | #1 |
Участник
|
В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте
****** Выделено отсюда AXAPTA, адью! *******
***** Внимание! Автором задана тема этой ветки - технологические возможности ПЛАТФОРМЫ. ******* ***** возможности функционала в соседней ветке ******* Был я там на собеседовании. В принципе, все ничего, но смутило предложение оформить договор подряда вместо трудового договора. Наколько я понял, они считают 1С более удобным и дешевым решением. В принципе, по технологическим возможностям платформа 1С сильно приблизилась к Аксапте (навскидку нет слоев и наследования классов, многое остальное уже есть). Проблема, как обычно, в функционале. Его либо нет, либо он никак не использует последние возможности последних версий платформы. Следует понимать, что рынок "вкусных" вакансий (от 2000 EUR) по 1С весьма ограничен (т.к. крупных проектов тоже немного). Хотя довольно много вакансий за 1000-1200 EUR - банальная поддержка многочисленных бухгалтерий. С голоду не помрете. |
|
|
За это сообщение автора поблагодарили: mazzy (-17), ibc (1), miklenew (11). |
26.11.2009, 23:02 | #2 |
Участник
|
Цитата:
Прекрати, пожалуйста, а? Нет, конечно. До Аксапты им как до Китая раком. |
|
30.11.2009, 10:54 | #3 |
Участник
|
Цитата:
Я, к сожалению, не копенгаген в Ax2009, но к "четверке" 1С 8.2 приблизилась очень сильно (повторюсь - не по функционалу, а по идеологии организации работы системы). Более того - процентов 40 нововведений версии 8.2 откровенно слямжено у Ax (вышла замечательная книжка Радченко на этот счет). Разница есть, но она сокращается очень быстро. Что касается функциональности, то 1С удалось-таки совершить маркетинговый прорыв. Я с удивлением обнаружил обширный сегмент заказчиков, верящих в то, что 1С:УПП - это ERP-решение уровня Аксапты. И мне даже приходится переубеждать их, объясняя, что эти системы если и похожи чем-то, так это суммами бюджета внедрения. Просто в одной системе нужно слегка корячить уже написанное, а в другой - придумывать и нагромождать отсутствующее. |
|
30.11.2009, 13:14 | #4 |
Участник
|
Чуть-чуть опоздал, создавая свою тему...
|
|
30.11.2009, 13:27 | #5 |
Участник
|
Все правильно сделал.
Хотел бы только обратить внимание Аксаптоведов на типичный выверт 1Сников: вы, Аксаптоведы, по-умолчанию говорите и спрашиваете о функционале. 1Сники по-умолчанию говорят и спрашивают о ПЛАТФОРМЕ! И это огромная разница. Сейчас получилось правильно - отдельная ветка по платформе и отдельная ветка по функционалу. Модератоский-оффтопик-ON. Вроде вменяемый человек был. А теперь стал "евангелистом", который в каждой ветке по делу и не по делу несет свою веру. Можешь ведь. Сейчас очень четко отделил сообщение по своей вере в Платформу и сообщение по теме исходной ветки. Что позволило безболезненно разделить твои сообщения по темам. Пожалуйста, хочешь нести свою веру - неси, флаг тебе в руки. Только не надо замешивать рекламу своей веры во все ветки направо и налево. Пока не научишься буду стулья ломать. Не проймет - буду просто удалять как это было с рекламой. Не смешивай! И не оффтопь! И не вынуждай модераторов оффтопить. И ничего с твоими сообщениями не сделается. Щас напишу ответ по теме. Модератоский-оффтопик-OFF. |
|
30.11.2009, 13:31 | #6 |
Участник
|
Цитата:
Сообщение от Сисой
Я, к сожалению, не копенгаген в Ax2009, но к "четверке" 1С 8.2 приблизилась очень сильно (повторюсь - не по функционалу, а по идеологии организации работы системы). Более того - процентов 40 нововведений версии 8.2 откровенно слямжено у Ax (вышла замечательная книжка Радченко на этот счет). Разница есть, но она сокращается очень быстро.
Повторюсь: Нет, не приближается даже к версии ax3.0. 1с только-только ввела трехуровневость и болеет теми же детскими болезнями бешенного трафика между клиентом и сервером, которыми болела ax2.1 и ax2.5. Пакетной обработки в платформе 1С до сих пор нет. По прежнему платформа 1С является однопоточной. С потоками нельзя работать даже на клиенте. Насколько я помню, даже обычного Progress Bar'а и то нет в этой платформе. Да, переписывают. НО: нет, до последних версий Аксапты им еще как до Китая раком. Это моя точка зрения в противовес твоей. Теперь, раз уж ты начал, начинай перечислять эти технологические возможности, по которым ПЛАТФОРМА приближается к Аксапте. Будем обсуждать предметно. |
|
30.11.2009, 14:09 | #7 |
1C
|
Код: Индикатор (ProgressBar) Свойства: Доступность (Enabled) МаксимальноеЗначение (MaxValue) МинимальноеЗначение (MinValue) Ориентация (Orientation) ОтображатьПроценты (ShowPercent) Подсказка (ToolTip) Рамка (Border) СтильОтображения (ShowStyle) ЦветРамки (BorderColor) ЦветФона (BackColor) Шаг (Step) Шрифт (Font) Описание: Индикатор предназначен для представления текущего состояния некоторого изменяющегося числового значения. Например, может применяться для наглядного представления выполнения процесса перебора строк таблицы значений или элементов массива. Для индикатора не предусмотрено формирование каких-либо событий, он также не может изменять связанные с ним данные. Недоступен на сервере 1С:Предприятие. Не используется в модуле внешнего соединения. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
30.11.2009, 14:17 | #8 |
Участник
|
Цитата:
1. Значит я ошибался 2. Теперь в платформе 1С есть ProgressBar. Ура! Мы нашли где они приблизились Давайте еще (В сторону) что есть в Аксаптовском туториале: |
|
30.11.2009, 14:28 | #9 |
Участник
|
Цитата:
Ты уверен, что это вопрос по платформе? По-моему, по функционалу. По крайней мере, в моей кастомизации УПП пакетный режим реализован (в оффлайне). Во всяком случае, платформа позволяет эмулировать пакетный запуск за счет фоновых и регламентных заданий. Цитата:
http://net-to-you.ru/programm/1cprog.../159-test.html Есть начиная с самой первой версии 8.0. |
|
30.11.2009, 14:32 | #10 |
Сам.AX
|
В 7.7 мы его рисовали в строке состояния как [|||||||______] 42%
И это было круто.
__________________
Возьми свет! |
|
30.11.2009, 14:39 | #11 |
Участник
|
Ок. Куда бы ты ни отнес, у нас есть ветка, где можно громко заявить о...
Про функционал - сюда Возможности функционала Dynamics AX и 1С УПП Цитата:
По-моему, ты о другом говоришь. но давай нас другие рассудят. Цитата:
Сообщение от Сисой
Принято. Кстати, сервер 1С умеет работать с потоками. Поэтому можно эмулировать асинхронные процессы примерно так:
http://net-to-you.ru/programm/1cprog.../159-test.html Имитация - это уже хорошо. Искренне поздравляю. А тупой таймер, который был еще в версии ax2.5, реализовать этой иммитацией можно? Или хотя бы автообновление формы по таймеру? Да, да. 1Сники - извините. просто меня здорово смутили разработки, которые выкладывают на инфостарте например, http://infostart.ru/public/16021/ ПрогрессБар есть. Правда с ограничениями, но есть. Ура, в этом наконец-то приблизилась к ax2.1 Давайте еще. |
|
07.12.2009, 12:25 | #12 |
Участник
|
Похоже больше нет тем.
Тогда попробую начать обосновывать свое мнение. Цитирую: Тогда еще некоторые темы для обсуждения. Пока кратко, без обоснования и ссылок (в надежде, что большинство понимает о чем идет речь): 1. Query В платформе 1С нет объекта, который позволяет ПРОГРАММИСТУ строить query программно. Аксаповеды, вы не поверите, но программисты 1С до сих пор парсят и правят тексты строк запросов. Т.е. если пользователь хочет добавить условия и фильтры, то программист должен позаботиться об этом и вставить куски кода с этими условиями в текствоый запрос. Для этого программисту нужно парсить строку запроса и вставлять туда условия со скобками, кавырками и прочей чешуей... Да, в 1С есть Построитель запросов - это некий конструктор, который позволяет мышкой создать и вставить текст запроса в код. Но с этим Построителем запросов нельзя работать программно в run-time. Только в design-time. Да, в 1С есть возможность задавать запросы в отчетах. И такие запросы пользователь может менять. Но в такие запросы нельзя влезть программно. И кроме того, такая возможность существует только в отчетах. Очень много Бла-бла-бла... на эту тему. Но надеюсь, что большинство участников, понимает о чем идет речь. 2. Кэширование таблиц В Аксапте очень большое значение уделяется кэшированию таблиц. См. книжку Dynamics Inside. Кэширование конечно же не поможет при работе с большими таблицами типа InventTrans, InventSettlement и прочее. Но кэширование заметно помогает при работе с настроечными таблицами (профили разноски, параметры компании, параметры валют, вевозможные группы, статусы и другие настройки) В результате треть запросов (и больше) Аксапта просто не отправляется на SQL-сервер. На кэшировании таблиц в Аксапте завязано очень многое. Так код может выполняться быстрее X++: while select custtrans where ... { custtable = custtable::find(custtrans.accountnum) } X++: while select custtrans where ... join custtable where custtable.accountnum == custtrans.accountnum { ... } X++: while select custgroup where custgroup.CustGroup == 'myGroup' { if( custgroup.paymtermid == 'myTerm' ) { ... } } X++: while select custgroup where custgroup.CustGroup == 'myGroup' && custgroup.paymtermid == 'myTerm' { ... } Те, кто говорят о том, что Аксапта не поддерживает T-SQL в полном объеме, просто не понимают о чем идет речь. Аксапта очень большое число "правильно написанных" запросов просто не посылает на SQL-сервер. И для разработчиков самой Аксапты, и для разработчиков приложений на этой самой Аксапты предельно важно, чтобы макисмально распределить нагрузку между AOS и SQL. Принцип простой - в многопользовательской среде - несколько простых и кэшируемых запросов намного лучше (с точки зрения производительности), нежели один сложный запрос. Выражаясь языком поговорок - лучше сорок раз по разу, чем один раз, но сорок раз. 3. Listerals vs Placeholders http://axapta.mazzy.ru/lib/literals_vs_placeholders/ В 1С просто нет такой штуки. Разработчики платформы 1С об этом не думали. Они вообще не думали, как SQL будет выполнять такие запросы. Комментарий: ниже Alexius и Vezunchik настойчиво попросили меня подтвердить мое высказывание про прекращение оптимизации. Я покопался и не смог найти подтверждение. О чем написал здесь. Поэтому свое высказывание про оптимизацию зачеркиваю. Спасибо вам за настойчивость. Однако, на мой взгляд это никак не влияет на исходный тезис, поскольку 1С с легкостью генерирует complex SELECT statements, для которых оптимизатор выбирает не самый оптимальный план. Мое мнение осталось прежним - разработчики платформы 1С не думали как будут выполняться такие сложные запросы.Ну и так далее. В общем, разработчики 1С повышают скорость работы единственного пользователя в монопольном режиме. А разработчики Аксапты прежде всего повышают скорость работы в многопользовательском режиме. (Где-то была статья про отличия в этих подходах. Вроде у Еременко. Не помню... Буду благодарен, если подскажете ссылки) Платформа еще не скоро приблизится Если и приближается, то к старым версиям Аксапты 2.1, 2.5, которые существовали лет 8-10 назад. Чтобы там ни провозглашали 1Сники. И как бы не пытались промыть мозги маркетингом. Последний раз редактировалось mazzy; 13.12.2009 в 21:41. Причина: про прекращение оптимизации запроса с 8ю таблицами. |
|
|
За это сообщение автора поблагодарили: sukhanchik (4), FE (1), alex55 (1). |
07.12.2009, 12:48 | #13 |
Участник
|
Цитата:
По существу. В 1С есть Система компоновки данных (что-то типа Построитель отчета v.2). В ней можно описать базовый запрос, а затем программно или мануально добавлять/удалять любые уточняющие конструкции (отборы, группировки, сортировки и т.п.). В 8.2 практически все отчеты базируются на СКД. Цитата:
Впрочем, механизм, безусловно, полезный (если он управляем разработчиком). Кстати, 1С умеет кэшировать объекты (для работы форм и объектного доступа "через точку"). Но конструкции класса Запрос всегда транслируются в SQL-команды СУБД, насколько мне известно. Ничего не сказано об объектной технике 1С. Мне гораздо приятнее работать с Документом, нежели россыпью таблиц. Ничего не сказано о том, что Аксапта застряла в своей идеологии на полпути - многие известные мне конструкторы учетных систем с поддержкой ООП умеют наследовать таблицы в составе контейнеров классов, описывающих объект предметной области. Да, признаю - DAX позволяет программисту строить куда более масштабируемые системы, нежели 1С:Предприятие (и все равно не на порядок, отличие по моим оценкам в 3-4 раза). |
|
07.12.2009, 13:05 | #14 |
Участник
|
Цитата:
Пользователю? Пользователь не наберет SQL запрос. Особенно если в конфигурации есть несколько тысяч объектов (сотни справочников, сотни документов, сотни регистров). Программисту? программисту нужен удобный механизм модификации запроса на основании галочек, которые выставил пользователь. А как раз такого механизма то и нет. Поэтому конечно же это не вопрос вкуса А вопрос - на кого ориентирована платформа. 1С предоставляет возможность ПРОГРАММИСТУ набрать запрос вручную. Но 1С не предоставляет пользователю никаких инструментов на пользовательском уровне (просто я кучу бла-бла-бла пропустил вокруг query). А программисту не предоставляет возможность удобно взаимодействовать с пользователем и удобно выполнять хотелки пользователей. Цитата:
Сообщение от Сисой
По существу. В 1С есть Система компоновки данных (что-то типа Построитель отчета v.2). В ней можно описать базовый запрос, а затем программно или мануально добавлять/удалять любые уточняющие конструкции (отборы, группировки, сортировки и т.п.). В 8.2 практически все отчеты базируются на СКД.
В модулях проведения, в периодических заданиях и в остальных местах программист доступа к СКД не имеет. Цитата:
Временные таблицы в Аксапте тоже есть. А вот записи обычных таблиц, которые попали в кэш, возращаются из кэша значительно быстрее, нежели с SQL Тут я вынужден, либо снова бла-бла-бла теорию... Либо отослать к книжке Inside Dynamics. Цитата:
Речь идет о данных. Как один из глобальных следствий того, что 1С не кэширует данные - это почти полное отсутствие настроечных таблиц, таблиц с правилами разноски на счета и т.п. Просто постоянные запросы к этим таблицам приведут к ступору SQL. Убедится в этом можно отключив кэширование в таблицах Аксапты (у меня были такие клиенты, которые жаловались на то, что "Аксапта неправильно работает с SQL". А потом выяснилось, что какие-то "деятели" переключили во всех таблицах режим кэширования с EntireTable и Found на NotInTTS)... Цитата:
Пример того, как получать данные http://axapta.mazzy.ru/lib/inventsumdate/ Такие же примеры есть и для ввода данных http://axapta.mazzy.ru/lib/journaltrans_insert/ Просто у 1С нет выбора на каком уровне работать Цитата:
Сообщение от Сисой
Ничего не сказано о том, что Аксапта застряла в своей идеологии на полпути - многие известные мне конструкторы учетных систем с поддержкой ООП умеют наследовать таблицы в составе контейнеров классов, описывающих объект предметной области. Да, признаю - DAX позволяет программисту строить куда более масштабируемые системы, нежели 1С:Предприятие (и все равно не на порядок, отличие по моим оценкам в 3-4 раза).
В Аксапте хотя бы пытались приблизиться при помощи map... |
|
07.12.2009, 13:19 | #15 |
Участник
|
Цитата:
Вывод из СКД доступен и на сервере. И есть класс ПроцессорВыводаРезультатаКомпоновкиДанныхВКоллекциюЗначений. Можно настроить СКД и вывести с ее помощью результат в таблицу или дерево значений. |
|
07.12.2009, 13:09 | #16 |
Участник
|
Цитата:
Сообщение от mazzy
3. Listerals vs Placeholders
http://axapta.mazzy.ru/lib/literals_vs_placeholders/ В 1С просто нет такой штуки. Разработчики платформы 1С об этом не думали. Они вообще не думали, как SQL будет выполнять такие запросы. За запросы в цикле на экзамене 1С:Специалист сразу дают по шапке. Я по пальцам руки могу пересчитать случаи, когда реально результат отбора данных на шаге цикла зависит от предыдущих итераций. Гораздо чаще можно отобрать необходимые данные в temptable (которая кэшируется на сервере 1С) и в цикле брать значения из нее. |
|
07.12.2009, 13:28 | #17 |
Участник
|
Цитата:
Сообщение от Сисой
В ряде случаев (отбор по критерию "равно") 1С просто решает эту проблему по другому. В языке запросов 1С есть оператор В (IN), который умеет принимать в качестве операнда список объектных значений. Такой запрос автоматически транслируется 1С в объединение кучи одинаковых подзапросов с UNION ALL и подстановкой разных значений в условия сравнения. План запроса один и тот же.
Если кто-то может дать ссылки или объяснить в двух словах (проще, чем в статье), пожалуйста, сделайте это. Хнык-хнык-хнык... Опять начали что ли? Опять попытка смазать разницу между "уже есть" и "можно сделать"? Да какая разница кто кому на каких курсах говорит? В типовых запросы в цикле есть? Есть. Надо исправлять? Надо. При чем здесь экзамен 1С:СПециалист? Кроме того, мы говорим о платформе. В том, то и дело, что в Аксапте иногда запрос в цикле выполняется быстрее и удобнее, нежели один сложный запрос. За счет кэширования. Например, Для каждого клиента/группы, для каждой номенклатуры/группы, для каждого рабочего центра и т.п... могут быть настроены свои правила разноски по счетам. Правила достаточно сложные. Объектов, для которых могут быть указаны правила разноски мжет быть до нескольких десятков. Неужели создавать один суперсложный запрос для таких вещей? Нет, отвечает Аксапта. Сделайте правильный запрос для выборки объектов. А правила разноски запрашивайте внутри. Поскольку правила скорее всего полностью попадут в кэш, то внутренние запросы выполнятся очень быстро. Что кардинально упрощает программирование и взаимодействие объектов. Псевдокод: X++: while select , , , , , , ... where... { = (); = (); = (); ... (, , ...); } Хочу обратить внимание, что код внутри цикла может быть распределен по другим методам, другим классам. Но он все равно будет быстрым из-за кэширования. Хочу также обратить внимание, что правила могут быть любыми - не только счета. Но и правила расчета себестоимости, правила резервирвоания, правила работы со складскими аналитиками, куча настроек в производстве, офигенная куча настроек лдя сводного планирования... и т.п. Понятно, что механизм кэширования тоже надо уметь настраивать. Понятно, что механизм кэширования не спасет в случае больших таблиц. У этого механизма есть своя область применения, где он работает очень хорошо. В 1Се этого просто нет. Поэтому разработчики конфигураций вынуждены правила просто зашивать в код. Чтобы избежать ddos-атак на SQL. Или вручную кэшировать. Цитата:
В 1С просто не делают по-настоящему настраиваемых конфигураций. Только программируемые Цитата:
Отобрать и брать - это отдельный код, который тоже надо программировать. за размером temptableтоже надо следить вручную |
|
07.12.2009, 14:05 | #18 |
Administrator
|
Цитата:
Сообщение от Сисой
В ряде случаев (отбор по критерию "равно") 1С просто решает эту проблему по другому. В языке запросов 1С есть оператор В (IN), который умеет принимать в качестве операнда список объектных значений. Такой запрос автоматически транслируется 1С в объединение кучи одинаковых подзапросов с UNION ALL и подстановкой разных значений в условия сравнения. План запроса один и тот же.
Цитата:
Сисой (как я понимаю) - говорит о том, что если нужно выбрать дискретные данные из таблицы (допустим выбрать 10 клиентов поименно), то 1С поддерживает оператор T-SQL IN и запрос, отсылаемый на сервер принимает вид: SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM IN ('Клиент1', 'Клиент2', 'Клиент3', ..., 'Клиент 10') Т.е. вместо того, чтобы слать 10 запросов вида SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = 'Клиент1' шлется одна вышеприведенная инструкция (это к слову о том, что 1С считает что лучше один большой запрос, чем 10 маленьких). Но вот мне кажется, что если в коде в 1С последовательно написать строчки: SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = 'Клиент1' и SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = 'Клиент2' То в БД уйдет 2 запроса и для каждого запроса будет строиться план. При этом mazzy говорит о том, что AX (если в коде будут написаны 2 такие же строчки) отправит в БД тоже 2 запроса: SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = :p1 и SELECT * FROM CUSTTABLE WHERE ACCOUNTNUM = :p1 А уже вместо переменной p1 ПОСЛЕ построения плана запроса будет подставлено конкретное значение. Разница между АХ и 1С тут будет в том, что план запроса в АХ будет строиться только 1 раз, а время, затрачиваемое БД на построение плана запроса и подстановку значения переменной несоизмеримо на больших объемах данных. А вот тут кстати - есть "хорошая новость" любителям временных таблиц (это относится к любым системам). Переливая данные во временную таблицу - мы теряем производительность на больших объемах данных, т.к. 1) Выборки из постоянных таблиц м.б. неполными (например формы в АХ тянут не все записи из таблицы, а только видимые + небольшой хвостик). А переливка во временную таблицу м.б. гораздо большего кол-ва записей, чем отображаемые. Но это больше к АХ относится как мне кажется 2) Помимо размера временной таблицы - никто не говорит про индексы. Переливая из постоянной таблицы данные во временную - мы фактически отказываемся от использования индексов - что естественно отражается на произовдительности на больших объемах данных. Подчеркну - если во временной таблице - небольшое кол-во данных - то указанные мною ограничения отсутствуют. Но как только во временную таблицу будут переливаться тысячи записей - то ограничения почуствуются
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 07.12.2009 в 14:08. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
10.12.2009, 16:39 | #19 |
Участник
|
|
|
10.12.2009, 17:35 | #20 |
Участник
|
ок. я понял, что вопрос задел за живое.
хм... помню, что Vadik давал ссылку на msdn. а вот здесь я говорил о 16 таблицах... еще нарыл SQL в Аксапте ищу дальше. |
|
Теги |
1c, платформа, сравнение систем |
|
|