Существуют ли недостатки у Axapta

[komar]

Цитата:

Сообщение от EVGL

Все нормально, нас услышали: по-видимому, в 4.0 будет 64-битный RecId. Тем самым проблема будет решена. Пока же есть одно решение: удалить все "лишние" и тестовые компании, которые консультанты десятками оставляют, и запустить функцию коррекции RecId.

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

[ppson]

Цитата:

Сообщение от komar

Или, например, что делать с таким технологическим ограничением, как recid?

После того как recid превысит допустимую норму, надо покупать SAP :-).
Попыток определить, систематизировать недостатки (ограничения в функционале, ошибки, фичи-баги), просмотреть качество и скорость работы поставщика с продуктом/клиентами отслеживается на данном форуме уже давно.

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

[mazzy]

Цитата:

Сообщение от komar

Если лишних нет, то выборочно чистить таблицы. Если таблицы уже вычистили, найти еще что-нибудь лишнее.

И не забыть о временных таблицах. Имено там большинство recid и "погибают".

Цитата:

Сообщение от komar

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

Долго же ты идешь к фразе "Microsoft must die"
Давай просто произнесем ее. И дальше будем говорить логично, по делу с цифрами и обоснованиями.

[komar]

Цитата:

Сообщение от EVGL

Все нормально, нас услышали: по-видимому, в 4.0 будет 64-битный RecId. Тем самым проблема будет решена.

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

[mazzy]

Цитата:

Сообщение от komar

Не решена, а отложена. То есть кислороду будет намного больше, но все-таки ограничение останется.

Сколько?!

(стучит ложками по столу и кричит) Цифры! Факты! ... Цифры! Факты! ...

[mazzy]

Кстати, в свое время (давным-давно) я делал аналогичный расчет для 1с.
http://1c.mazzy.ru/articles/howmany/

komar, pavel, а что в других системах?
Есть ли подобные ограничения?
Сколько записей можно максимально создать в Scala, например?

Цитата:

Сообщение от komar

Не решена, а отложена. ...

Наверное все таки решена т.к. 2 в 64 это ну очень много

[TasmanianDevil]

Сергей, если Вас интересуют другие системы - в ГАЛАКТИКЕ уникальный идентификатор записи внутри таблицы(не системы !!!) является 64-битным знаковым целым,первый 1 байт используется для служебной идентификации параметров используемой платформы БД , остальные 7 байт на идентификатор , т.е. до 2^56 -1 = 72 057 594 037 927 935 записей в каждой из 32000 таблиц (было там такое ограничение) т.е всего в системе может быть до 72 057 594 037 927 935 Х 32 000 = 2 305 843 009 213 693 920 000 записей - там скорее всего сама платформа брякнется, нежели системная генерация идентификаторов.

[mazzy]

Спасибо, TasmanianDevil

[komar]

Цитата:

Сообщение от mazzy

Сколько?!

(стучит ложками по столу и кричит) Цифры! Факты! ... Цифры! Факты! ...

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

Что касается Scala, то, может не стоит засорять ветку оффтопиком? Все же раз вопрос возник, то отвечу - аналога recid, насколько мне известно, нет. Даже если бы он был, то ответ "в лоб" дать было бы невозможно, так как некоторые данные хранятся в таблицах, отдельных для каждой компании (подобно Navision), а некоторые - в таблицах, создающихся для каждого финансового года.
На сем обсуждение других систем прошу продолжать в специально заведенных для них ветках.

[komar]

Цитата:

Сообщение от lagr221374

Наверное все таки решена т.к. 2 в 64 это ну очень много

Может быть будет решена (если неофициальная информация верна) когда мы, может быть, увидим рабочую версию 4.0. В светлом, так сказать, будущем. Хотя есть надежда,что уже нынешнее поколение будет жить при коммунизме!

[mazzy]

Цитата:

Сообщение от komar

Что касается Scala, то, может не стоит засорять ветку оффтопиком? Все же раз вопрос возник, то отвечу - аналога recid, насколько мне известно, нет. Даже если бы он был, то ответ "в лоб" дать было бы невозможно, так как некоторые данные хранятся в таблицах, отдельных для каждой компании (подобно Navision), а некоторые - в таблицах, создающихся для каждого финансового года.
На сем обсуждение других систем прошу продолжать в специально заведенных для них ветках.

Ок. Спасибо. Здесь Scala

Вернемся к недостаткам Аксапты.
Ты начал про RecID. Завершим тему? Что скажешь насчет дефрагментации и моей оценки? Она справедлива? Какова твоя оценка (количество записей, размер базы) когда данный недостаток может проявить себя?

[komar]

Цитата:

Сообщение от mazzy

Давай просто произнесем ее. И дальше будем говорить логично, по делу с цифрами и обоснованиями.

Погоди! Я как раз и пытаюсь вытащить эту ветку на "по делу и с обоснованиями". Раз уж никто не хочет говорить про функциональность, прикрываясь "67 заданиями", и раз уж работа службы поддержки признана идеальной (без всяких фактов и обоснований) и попынка выйти на старые баги не признается недостатком системы (безо всяких фактов и обоснований) предложено было для разнообразия пообсуждать самые известные из технологических граблей - утечки памяти и recid.
Про масдай пока никто не говорит, МС еще пригодится - ведь не только у Навижна портал на sharepoint

[mazzy]

Цитата:

Сообщение от komar

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

Ты щас кому сказал?

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

Хочешь составить список недостатков? Возьми эту ветку в зубы и составь. Дело будет полезное. Назови этот сипсок: 100 недостатков, которые губят Аксапту

Хочешь пожаловаться на жизнь? Ну, дык я с тобой соглашусь - жизнь тяжелая штука.
Хочешь сказать, что Аксапта полный отстой? С этим не соглашусь
Хочешь сказать, что в Аксапте есть недостатки и их полно? А вот с этим соглашусь, но тут же добавлю, что есть и достоинства.
И т.п.

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

[George Nordic]

Ну! Так давай! Вот ветка, где можно обсудить все баги и кривизну Российской локализации:
Российская функциональность в Microsoft Axapta
Просто RecId и утечка памяти не локализованы т.е. с местных-то спросить нечего А вот насчет функционала - можно и поспорить, что и как было сделанно, и почему так, и как надо было правильно.

С Уважением,
Георгий.

[komar]

Цитата:

Сообщение от mazzy

Ок. Спасибо. Здесь Scala

Вернемся к недостаткам Аксапты.
Ты начал про RecID. Завершим тему? Что скажешь насчет дефрагментации и моей оценки? Она справедлива? Какова твоя оценка (количество записей, размер базы) когда данный недостаток может проявить себя?

Про дефрагментацию на форуме есть весьма оживленная дискуссия Как выполнять дефрагментирование RecID. Итогом ее можно считать вывод о том, что есть стандартная процедура дефрагментации, есть участники, которые считают ее неприменимой, и есть альтернативные, написанные партнерами процедуры, и некоторые участники считают их неоптимальными. Закончилась дискуссия на разборках со ссылками в "Трансляции по ГК", от рассмотрения структуры данных которой участники утомились, и более ничего дельного не сказали.
Оценки по количеству записей, приведенные в той ветке, кажутся вполне целесообразными, однако следует помнить, что идентификатор отъедает именно запись в таблице, а каждая бизнес-транзакция может задействовать несколько таблиц, и чем больше функциональности используется, и чем больше дополнительной функциональности напрограммировано, тем ближе маленькая белая лисичка.

[mazzy]

Цитата:

Сообщение от komar

...идентификатор отъедает именно запись в таблице...

Все намного хуже
Идентификатор отъедает запись в компании, а не в таблице.

Прос маленькую лисичку мужского рода надо начинать думать при подходе к количеству записей в 2млрд. Это примерно около 400Гб для базы.

С этим согласен?

[komar]

Цитата:

Сообщение от mazzy

Все намного хуже
Идентификатор отъедает запись в компании, а не в таблице.

Прос маленькую лисичку мужского рода надо начинать думать при подходе к количеству записей в 2млрд. Это примерно около 400Гб для базы.

С этим согласен?

Не силен в арифметике :-) нодаже это не есть заоблачный объем для крупной компании. Где-то 5 лет работы - с этим согласен?

P.S. А указание компании в профиле для сотрудников МБС будет? А то scala и sap присутствуют, а МБС все еще выступает как собственные довольные клиенты. У гостей сайта может создаться неверное впечатление...

[mazzy]

Цитата:

Сообщение от komar

Не силен в арифметике :-) нодаже это не есть заоблачный объем для крупной компании. Где-то 5 лет работы - с этим согласен?

Согласен.

Цитата:

Сообщение от komar

P.S. А указание компании в профиле для сотрудников МБС будет? А то scala и sap присутствуют, а МБС все еще выступает как собственные довольные клиенты. У гостей сайта может создаться неверное впечатление...

Не знаю. Сначала спросим. Открывай новую ветку для этого.

[Pavel]

Цитата:

Сообщение от komar

это не есть заоблачный объем для крупной компании. Где-то 5 лет работы - с этим согласен?

Есть компании, которые на XALе в год за 200ГБ наколачивают. Хорошая практика открывать базы/компанию под финансовый год. Придется переносить остатки и открытые записи, зато легко изменять настройки системы, не падает быстродействие.