Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 быстрое получение остатков на дату  [new]
DobPilot
Member

Откуда:
Сообщений: 114
Дано таблица, в которой будут часто делаться запросы на получение остатка на дату, вида

select summ(balance) from table where date < :beginDate group by userAccount;

Возникает мысль, с увеличением числа строк в таблице будут медленнее выполняться запросы. -)

Вопрос позновательный, как бытовую проблему можно решить на различных СУБД? Заодно можно и тестики поделать, различных решений. )


з.ы.
Сам пользую postreSQL и задал вопрос в соотв. топике.
28 ноя 07, 01:02    [4972517]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Yo.!
Guest
в оракле для такой задачи есть materialized view, которое будет хранить агрегты (например на день) и подсовывать оптимизатору это вью вместо оригинальной таблички.
28 ноя 07, 01:55    [4972586]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Думаю эта задача во всех СУБД решается с помощью триггера и еще одной таблицы. В случае Оракла - триггер и таблица системные, что несомненно красивее.
-------------------------------------------------------
Автор благодарит алфавит за любезно предоставленные ему буквы.
28 ноя 07, 10:02    [4973040]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
В MS SQL задача решается с помощью построения indexed view. Оптимизатор сможет использовать это представление и без переписывания оригинального запроса на использование представления в нем вместо базовой таблицы.
28 ноя 07, 10:27    [4973232]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Завести себе фиксированные остатки.
Тогда с ростом таблицы скорость запроса не будет расти выше
определенного уровня.

Posted via ActualForum NNTP Server 1.4

28 ноя 07, 11:31    [4973781]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
DobPilot
Возникает мысль, с увеличением числа строк в таблице будут медленнее выполняться запросы. -)...

Для этих целей, как Вам правильно подсказали выше - используется подход DataWarehouse...

Good luck!
28 ноя 07, 13:07    [4974622]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Крутая у вас таблица получится.... Кол-во номенклатур * Кол-во дат.... = ? Со временем таблица еще больше получится....
18 дек 07, 10:23    [5061309]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Гликоген
Member

Откуда:
Сообщений: 846
Не зависит от СУБД.
В тупых учетных системах - только движения и начальный+текущий остаток.
В чуть более продвинутых (1С) - снимок остатка на каждый отчетный период (обычно месяц) + движения между.
В хранилищах данных - как правило, на каждый день.
18 дек 07, 10:55    [5061511]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
мне кажется это вопрос больше в тему "Проектирование БД"
18 дек 07, 11:04    [5061564]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
TORT
Крутая у вас таблица получится.... Кол-во номенклатур * Кол-во дат.... = ? Со временем таблица еще больше получится....
Ну если по большей части номенклатур остатки меняются относительно редко, то и не надо по ним остатки на каждую дату хранить. Добавлять записи, только при изменении остатка. Табличка будет не больше, чем таблица движений, а остатки безо всякого суммирования будут получаться.
18 дек 07, 11:20    [5061714]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Если остатки меняются редко, то и записей о движении будет немного, а следовательно и
select sum(...) будет работать недолго....ИМХО... Зачем огород городить?
18 дек 07, 12:19    [5062236]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
TORT
Если остатки меняются редко, то и записей о движении будет немного, а следовательно и
select sum(...) будет работать недолго....ИМХО... Зачем огород городить?
затем чтобы не суммировать все данные, а взять одну нужную
18 дек 07, 12:35    [5062375]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
TORT
Если остатки меняются редко, то и записей о движении будет немного, а следовательно и
select sum(...) будет работать недолго....ИМХО... Зачем огород городить?

Типичная структура движений такова: из 10-20 тысноменклатурных единиц по 95 процентам движения происходят пару раз в месяц. Процентам по 4 - раз в два-три дня, а по оставшимся - несколько раз в день. Соответственно для 95 процентов вполне можно и суммировать (за год накопится 20-30 записей), но вот по этому проценту (а именно по нему остатки нужны наиболее часто) суммировть потребуется уже довольно много. Соответственно имея записи об остатках на моменты движений мы не раздуваем существенно таблицу остатков, но зато время получения остатка не зависит от активности номенклатуры.
18 дек 07, 13:02    [5062557]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Если я правильно понял, то Вам придется хранить остатки товара на каждый день, в независимости от того было по нему движение в этот день или нет... Соответственно и таблица у вас будет размером Кол-во товаров * Кол_во дней = Много. А иначе Вам придется все равно по движению суммировать данные... КМК, нет смысла делать такую таблицу... Поправьте меня, если я заблуждаюсь...
18 дек 07, 13:07    [5062607]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Быть может я не правильно понимаю уровень группировки(день, месяц, год) данных? Но по-поему это не играет никакой роли... Либо Вы храните остатки по всем! товарам на каждый день!...Либо СУБД проще и быстрее будет делать select sum(...)
18 дек 07, 13:10    [5062620]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
TORT
Поправьте меня, если я заблуждаюсь...
Поправляю.

Имеем таблицу
Остатки
Номенклатура ссылка
Значение число
Начало дата
Конец дата
При совершении движения в этой таблице у текущей записи по номенклатуре выставляется "Конец" и добавляется новая. Если в один день происходит несколько двжиений, то мы просто модифицируем запись текущую запись.
Таким образом число записей не превышает количества движений, а остаток на любой день достается запросом без суммирования:
select Значение from Остатки where Номенклатура=:id and Начало <= :data and Конец > :data
Наличие индексов делает запрос быстрым. Особые эстеты могут его оптимизировать.
Я не говорю, что это единственное верное решение, но в некоторых случаях оно работает очень хорошо.
18 дек 07, 13:30    [5062723]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Я не совсем понимаю зачем Начало и Конец... Поясните, если не трудно...
18 дек 07, 13:43    [5062841]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
TORT
Я не совсем понимаю зачем Начало и Конец... Поясните, если не трудно...
Для того чтобы не делать sum и не хранить остатки за все даты.
18 дек 07, 13:57    [5062947]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
TORT
Я не совсем понимаю зачем Начало и Конец... Поясните, если не трудно...
Да, я понял - вы хотите сказать, что можно обойтись только Началом. Можно, но в этом случае запрос для получения значения будет более сложным - без подзапроса не обойтись.
18 дек 07, 13:58    [5062961]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Спасибо за подробное пояснение... Но все-таки хотелось бы уточнить... Таким образом Вы предлагаете хранить интервалы, на которых остатки были неизменными? Я правильно понял? Вы тестировали данный подход? Если не серк
18 дек 07, 13:59    [5062965]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Если не секрет на каой СУБД? Какой интервал движения? И какое кол-во номенклатур?
18 дек 07, 13:59    [5062972]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Интересен механиз реализации этого подхода...
18 дек 07, 14:01    [5062984]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
TORT
Спасибо за подробное пояснение... Но все-таки хотелось бы уточнить... Таким образом Вы предлагаете хранить интервалы, на которых остатки были неизменными? Я правильно понял?
Да, правильно.

TORT
Вы тестировали данный подход? Если не серк
Не только тестировал, но и промышленно эксплуатировал. :)

TORT
Если не секрет на каой СУБД? Какой интервал движения? И какое кол-во номенклатур?
О СУБД вы могли из моего профиля догадаться - Oracle. Но думаю, что такой подход мог бы на любой СУБД использоваться.
Количественные характеристики: из реально работающих есть примеры в которых более 100 тысяч учетных единиц и сотни тысяч движений в день. Но это мало о чем говорит, так как надо учитывать используемую технику и то, что реальные системы не только движения учитывают. Голый тестовый пример для сравнения этой модели с другими я не собирал.
18 дек 07, 14:09    [5063041]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
TORT
Member

Откуда:
Сообщений: 1115
Вопрос с реализацией? Как формируется такая таблица? Триггеры, специальная ХП, клиентское приложение?
18 дек 07, 14:19    [5063139]     Ответить | Цитировать Сообщить модератору
 Re: быстрое получение остатков на дату  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
TORT
Вопрос с реализацией? Как формируется такая таблица? Триггеры, специальная ХП, клиентское приложение?
Триггеры или ХП - это не очень интересный вопрос. У нас было несколько реализаций. Стандартно была процедура, добавляющая движения, она же и остатком занималась. Но в триггере это выглядело бы точно так же.
Гораздо более интересный вопрос с обеспечением сериализации - если несколько сеансов одновременно делают движения по одной и той же учетной единице. В общем-то обычная блокировка здесь помогает, но был у нас один исключительный случай, когда учетных единиц было мало (порядка сотни), а конкурирующих транзакций - много (до полусотни процессов и десятки тысяч операций в час у каждого). Тут задержки на блокировках становятся посущественней. Для этого случая был другой вариант, когда заполнением этой таблицы занимался отдельный фоновый процесс.
18 дек 07, 15:22    [5063661]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить