Остатки на дату.

[UNRW]

код я брал не из нашей рабочей базы... писал на память

[Recoilme]

Цитата:

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

код я брал не из нашей рабочей базы... писал на память

1. на 16 миллионах этот запрос будет работать часа полтора так что в чем то мази прав, но только в чем то, потому что на стандартных классах это вообще не работает
2. Если сделать инвенттранс нормальным, построеным не по варчарам а поинтежеровским полям (вместо итемид - рекид и т.п.) - этот запрос будет работать на тех же 16 миллионах - 50 секунд

пункт 2 - это так, к слову хотя может пригодится построителям хранилищ для отчетности, буде таковые вообще есть в природе на этом форуме

[mazzy]

Цитата:

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

1. но только в чем то, потому что на стандартных классах это вообще не работает

Не понял.
Что "это"?

Цитата:

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

2. Если сделать инвенттранс нормальным, построеным не по варчарам а поинтежеровским полям (вместо итемид - рекид и т.п.) - этот запрос будет работать на тех же 16 миллионах - 50 секунд

Это революция.
Переход от естественных ключей к исскусственным.
Такое вряд ли будет в ближайших версиях.

[Recoilme]

Цитата:

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

Не понял.
Что "это"?


Это революция.
Переход от естественных ключей к исскусственным.
Такое вряд ли будет в ближайших версиях.

1. Ответил Владимир Максимов:
InventSumDatePhysicalDim:: onHandQty() - отработал примерно за 50 минут
Прямой запрос в Query Analyzer по схеме: InventSum - SUM(InventTrans) выполнился за 2 минуты (т.е. остаток на сегодня минус все складские проводки до интересующей даты)

значит для 16 миллионов - примерно 8 часов. А ещё нужен приход и расход = примерно 24 часа на построение оборотки = не работает

ЗЫ: я пробовал, через 1,5 часа снял задачу, у меня терпения не хватило

2. Скорее наооборот Переходе от искусственных ключей Аксапты построенным по текстовым полям к естественным ключам для СУБД построенным по целочисленным полям.
Об этом надо было думать Дамгардам при проектировании базы. Сейчас это можно использовать при построении хранилищ на основе аксапты

[mazzy]

Цитата:

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

1. Ответил Владимир Максимов:

Все равно не понял.
Ну, да ладно. Надеюсь другие разобрались

Цитата:

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

2. Скорее наооборот Переходе от искусственных ключей Аксапты построенным по текстовым полям к естественным ключам для СУБД построенным по целочисленным полям.

Искусственные и естественные ключи - это термины.
Поищите. Найдете много интересного.
Поищите на этом форуме для начала. Тема обсуждалась неоднократно.

Цитата:

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

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

Они как раз думали.
Просто тогда СУБД были другими.
Тогда приортитеты были другими.
...Тогда - это уже 20 лет назад
http://axapta.mazzy.ru/lib/names/#chronicle

[Recoilme]

Цитата:

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

Все равно не понял.
Ну, да ладно. Надеюсь другие разобрались


Искусственные и естественные ключи - это термины.
Поищите. Найдете много интересного.
Поищите на этом форуме для начала. Тема обсуждалась неоднократно.


Они как раз думали.
Просто тогда СУБД были другими.
Тогда приортитеты были другими.
...Тогда - это уже 20 лет назад
http://axapta.mazzy.ru/lib/names/#chronicle

1998 Mar Выпущена система Damgaard Axapta 1.0 - объектно-ориентированная, трехуровневая архитектура клиент/сервер, международная, многопользовательская. MS SQL 6.5, Oracle 7.0

что-то мне подсказывает что в 98 году суррогатные ключи давали 100 очков вперед естественным. Пусть это остается на их совести по крайней мере я в терминологии разобрался

[kvan]

Цитата:

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

1998 Mar Выпущена система Damgaard Axapta 1.0 - объектно-ориентированная, трехуровневая архитектура клиент/сервер, международная, многопользовательская. MS SQL 6.5, Oracle 7.0

Аксапта "выросла" из Конкорда, а он появился гораздо раньше 1998 года ...