Проблема производительности при использовании виртуальных компаний.

[7Up]

Цитата:

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

так у Вас счетчик RecId переполнится в любом случае очень скоро - они из общего пула берутся, никакая "проверка кодов записей" не поможет
- вариант с виртуальными компаниями конечно интересный, хотя и небезгеморройный с точки зрения настройки и переноса данных
- посмотрите на стр. 524 Databases Advanced - там описана возможность генерировать уникальные RecId в пределах таблицы и компании, а не компании. Вариант тоже не без проблем, первая же "проверка кодов записей" эту идиллию порушит, опять же надо что-то делать с существующими данными (ссылки по RecId)

P.S. как представил себе SysDatabaseLog по строкам заказов, которых до 400 тысяч в день - жуть
P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?

Не понял про стр. 524 Databases Advanced. Можно уточнить что за книжка имеется в виду. Если так можно - эффект будет тот же, только dataareaid меняться не будет.
Про dataareaid - оно первое во всех индексах. Специалистами высказывается опасение, что разные dataAreaId приведут к тормозам.

[Recoilme]

Цитата:

Сообщение от 7Up

Про dataareaid - оно первое во всех индексах. Специалистами высказывается опасение, что разные dataAreaId приведут к тормозам.

Вот и слушайте Ваших специалистов, а не по форумам шляйтесь))

[Михаил Андреев]

Цитата:

Сообщение от 7Up

до 400 тыс строк заказов в день. Все остальное пропорциоанально.
ЛОги на все основные таблички.

Любопытно, откуда возьмутся эти поллимона строк? Кто их набьёт? Если люди, то их не менее 1-2 тыс. должно быть. И зачем логи на все основные таблицы?
Напоминает анекдот про бензопилу и суровых сибирских мужиков.
Либо дерево не то, либо инструмент не тот.
При таком объёме дублирование RecId - мелочь по сравнению с кучей других проблем. Как вы склад закрывать собираетесь? А сводное планирование как будет работать? И как одновременно тысяча человек будут работать с одними и теми же таблицами, взаимными блокировками и т.п.?
Чисто гипотетически:
1. Создание виртуальных компаний проблему RecId вряд ли решит. Да и ни к чему её таким образом решать: реально важно отсутствие дублирования RecId в одной компании одной таблицы.
2. Убирание dataareaid тоже вряд ли даст эффект в проблеме RecId. Не думаю, что эффект по производительности будет очень существенен: в большинстве таблиц индексы строятся с его учётом, а базы данных очень хорошо умеют сами оптимизировать запросы. Поэтому, на мой взгляд, гораздо эффективнее построить администратора базы данных, чем убрать dataareaid.

[mit]

это в разработке и уже 500 гиг?
с виртуальными компаниями точно не решение. в таком случае придется писать процедуру дефрагментации на t-sql и трогать только нужные таблицы

[Writer]

Господа, если мы с вами пока говорим о теоретическом проекте, то давайте говорить об Axapta 4.0 и 64 битной версии. Тогда recid будет 64 бита и количество записей будет ± 9 223 372 036 854 775 808 вопрос будет снят с повестки дня

[glibs]

Полностью согласен с участником Михаил Андреев.

Не с того конца проблемы ищете.

И что у вас за компания (чем конкретно занимаетесь)? Склько человек там сидит на вводе только одних заказов?

Офис у вас один? А складское помещение у вас тоже одно?

Неужели нельзя разделить на несколько компаний?

[7Up]

Цитата:

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

Полностью согласен с участником Михаил Андреев.

Не с того конца проблемы ищете.

И что у вас за компания (чем конкретно занимаетесь)? Склько человек там сидит на вводе только одних заказов?

Офис у вас один? А складское помещение у вас тоже одно?

Неужели нельзя разделить на несколько компаний?

Народу сидит относительно не много, компанию и сферу деятельности называть не буду. Заказы генерятся по шаблонам, а затем редактируются пользователями. Естественно индивидуальный подход к клиенту весьма ограничен, а менеджер должен обеспечить определенные итоговые параметры. Логи нужны для выяснения истории возникших проблем (отгрузили не то, не тому и т.д.) и виновных.
Разумеется recId не самый главный вопрос, но данная тема посвящена именно ему.

[Writer]

Цитата:

Сообщение от 7Up

Логи нужны для выяснения истории возникших проблем (отгрузили не то, не тому и т.д.) и виновных.

А зачем вам все логи в данном случае. Включите на таблицах аудит записи кто создал, кто модифицировал. Логами отслеживайте только ключевые моменты. Опыт показывает, что 90% процентов всех вопросов можно решить с помощью аудита записи и выстроенного бизнес-процесса по сферам ответственности.

[Dron AKA andy]

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

[Delfins]

Dron AKA andy, помоему имелось ввиду, что если ты добавишь сам поле в индекс, то сможешь поменять позицию.. По дефолту оно первое идет, как скрытое (если таблица c SaveDataPerCompany )