|
![]() |
#1 |
Модератор
|
Цитата:
Сообщение от 7Up
до 400 тыс строк заказов в день. Все остальное пропорциоанально.
ЛОги на все основные таблички - вариант с виртуальными компаниями конечно интересный, хотя и небезгеморройный с точки зрения настройки и переноса данных - посмотрите на стр. 524 Databases Advanced - там описана возможность генерировать уникальные RecId в пределах таблицы и компании, а не компании. Вариант тоже не без проблем, первая же "проверка кодов записей" эту идиллию порушит, опять же надо что-то делать с существующими данными (ссылки по RecId) P.S. как представил себе SysDatabaseLog по строкам заказов, которых до 400 тысяч в день - жуть P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#2 |
злыдень
|
Цитата:
Сообщение от Vadik
P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?
Конечно я говорю о разнице - в использовании поля DataAreaId (его нет, включен ключ nodataareaid) и когда оно есть и используется во всех индексах напропалую, а не о том случае - писать туда "DAT" или хрень какую ещё
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
![]() |
#3 |
Участник
|
Цитата:
Сообщение от Recoilme
Если буквально и в двух словах : "Пипец производительности"
Конечно я говорю о разнице - в использовании поля DataAreaId (его нет, включен ключ nodataareaid) и когда оно есть и используется во всех индексах напропалую, а не о том случае - писать туда "DAT" или хрень какую ещё join * from table2 where table2.dataareaId == "vir" что помешает БД использовать правильные индексы? |
|
![]() |
#4 |
злыдень
|
Цитата:
Сообщение от 7Up
select * from table1 where table1.dataareaId == "dat"
join * from table2 where table2.dataareaId == "vir" что помешает БД использовать правильные индексы? Ключевое слово: NODATAAREAID Не будет этого поля там "dataareaId ". Совсем не будет.
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
![]() |
#5 |
Участник
|
Цитата:
Сообщение от Recoilme
Ещё раз: ОТКЛЮЧЕНИЕ DATAAREAID ДАСТ ОФИГЕННЫЙ ВЫИГРЫШ ПО ПРОИЗВОДИТЕЛЬНОСТИ
Ключевое слово: NODATAAREAID Не будет этого поля там "dataareaId ". Совсем не будет. |
|
![]() |
#6 |
Роман Долгополов (RDOL)
|
Цитата:
Сообщение от 7Up
NODATAAREAID - имеется в виду SaveDataPerCompany = No?
По поводу опасений использования данной возможности - по крайней мере три очень нехилые розничные сети работают несколько лет с таким ключиком. Версии 3.0 от без СП до KR1. Проблем никаких. А насчет производительности - протестируйте сами и решите сами. Не хочется ввязываться в очредную войнушку ![]() Последний раз редактировалось db; 24.07.2006 в 20:19. |
|
![]() |
#7 |
Участник
|
Интересно было бы услышать цифры - какой выигрыш дает noDataAreaId
2 vadic. Все-таки насчет настройки выделения recId для отдельных таблиц не могли бы вы уточнить как именно это можно настроить или где посмотреть.
Если вдруг волшебный ключ noDataAreaId дает существенное улучшение производительности ваш вариант становится оптимальным. |
|
![]() |
#8 |
Модератор
|
Ничего не имею против NODATAAREAID, однако хотел бы предложить вернуться к обсуждению проблемы генерации RecId в системе с 400000 строками заказов в день. Правда, проблема оказалась виртуальной
![]() ![]() P.S. И, раз уж пошла такая пьянка, предпочел бы вместо NODATAAREAID отключить SaveDataPerCompany на "больших" таблицах в AOT. Надежнее как-то ![]()
__________________
-ТСЯ или -ТЬСЯ ? |
|
![]() |
#9 |
злыдень
|
Цитата:
Сообщение от Vadik
Ничего не имею против NODATAAREAID, однако хотел бы предложить вернуться к обсуждению проблемы генерации RecId в системе с 400000 строками заказов в день.
Допустим завтра к Вам приходят и говорят, через месяц у нас в аксапте будет до 400 000 строк заказов в день. Т.е. 2000 заказов по 200 строк. Знаете что я посоветую? Подумать о количестве записей? 64 битный ключ на 4 аксапте? Нет! Я посоветую подумать о смене работы)) Резюме надо составлять при таких объемах, а не по форуму писать)) Засим теоретическую часть обсуждения аксапты на 400000 строк продаж предлагаю закрыть. Желающие могут засечь время создания и разноски заказа на 200 строк, умножить на 2000 , мыслено представить блокировки,24 на 6 и прочие прелести. Людям с развитым воображением лучше поберечь здоровье и не представлять))
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
![]() |
#10 |
Участник
|
Цитата:
Сообщение от Recoilme
Хорошо. Давйте вернемся ))
Допустим завтра к Вам приходят и говорят, через месяц у нас в аксапте будет до 400 000 строк заказов в день. Т.е. 2000 заказов по 200 строк. Знаете что я посоветую? Подумать о количестве записей? 64 битный ключ на 4 аксапте? Нет! Я посоветую подумать о смене работы)) Резюме надо составлять при таких объемах, а не по форуму писать)) Засим теоретическую часть обсуждения аксапты на 400000 строк продаж предлагаю закрыть. Желающие могут засечь время создания и разноски заказа на 200 строк, умножить на 2000 , мыслено представить блокировки,24 на 6 и прочие прелести. Людям с развитым воображением лучше поберечь здоровье и не представлять)) Сервер БД IBM 460 с одной стойкой, БД-Oracle. Единственное но: базенка всего 30 Гб. В целом понимаю предыдущего оратора. Рассматриваемые объемы велики для аксапты. Да, аосы - 3 штуки 2-х процессорные. Последний раз редактировалось 7Up; 25.07.2006 в 10:12. |
|
![]() |
#11 |
Участник
|
Цитата:
Сообщение от Recoilme
Хорошо. Давйте вернемся ))
Допустим завтра к Вам приходят и говорят, через месяц у нас в аксапте будет до 400 000 строк заказов в день. Т.е. 2000 заказов по 200 строк. Знаете что я посоветую? Подумать о количестве записей? 64 битный ключ на 4 аксапте? Нет! Я посоветую подумать о смене работы)) ЗЫ Ждем официальных тестов от Майкорсофт по производительности Ax 4.0 в сравнении с 3.0 |
|
![]() |
#12 |
Участник
|
Цитата:
Сообщение от Vadik
P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?
__________________
Дом поросенка должен быть крепостью. (Наф-Наф, полн. собр. соч., т.5, стр. 286) |
|
![]() |
#13 |
Участник
|
Цитата:
Сообщение от Vadik
так у Вас счетчик RecId переполнится в любом случае очень скоро - они из общего пула берутся, никакая "проверка кодов записей" не поможет
- вариант с виртуальными компаниями конечно интересный, хотя и небезгеморройный с точки зрения настройки и переноса данных - посмотрите на стр. 524 Databases Advanced - там описана возможность генерировать уникальные RecId в пределах таблицы и компании, а не компании. Вариант тоже не без проблем, первая же "проверка кодов записей" эту идиллию порушит, опять же надо что-то делать с существующими данными (ссылки по RecId) P.S. как представил себе SysDatabaseLog по строкам заказов, которых до 400 тысяч в день - жуть P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется? Про dataareaid - оно первое во всех индексах. Специалистами высказывается опасение, что разные dataAreaId приведут к тормозам. |
|
![]() |
#14 |
злыдень
|
Цитата:
Сообщение от 7Up
Про dataareaid - оно первое во всех индексах. Специалистами высказывается опасение, что разные dataAreaId приведут к тормозам.
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
Теги |
recid, виртуальные компании, производительность |
|
|