Dimitry Sibiryakov
Ну, не считая ужасов про
тысячу запросов в минуту.


Ну если не считая, тогда конечно :)
Складской учет вас ждет, не теряйте времени

Dimitry Sibiryakov
Ну а вы можете вернуться к своему героическому труду по эмуляции мускуля
на оракуле. Не смею мешать.


Я что-то пропустил в этой жизни :(
Мускуль то откуда взялся ? Я ему не поклоняюсь

Dimitry Sibiryakov
Gluk (Kazan)Мускуль то откуда взялся ? Я ему не поклоняюсь

Из первого поста. Вы поклоняетесь его манере блокировок на любой чих.
Posted via ActualForum NNTP Server 1.4

Неа, это вы воля ваша сами придумали
Просто я не делаю из блокировок ПУГАЛА

Dimitry Sibiryakov
Gluk (Kazan)это вы воля ваша сами придумали

Да неужели? У меня все ходы записаны!

"Столь лишние телодвижения чтобы избежать банальнейшей коротюсенькой
блокировочки на update-е баланса (которая еще и не столь часто происходит)."
Posted via ActualForum NNTP Server 1.4

ичо ??? здоровое отсутствие паранои по поводу вполне регламентной блокировки

Dimitry Sibiryakov
Gluk (Kazan)
здоровое отсутствие паранои по поводу вполне регламентной блокировки

Нежелание устранять узкое место поскольку "сервер железнеый, справится".
Posted via ActualForum NNTP Server 1.4

Ваше элегантное решение создаст несколько гораздо более узких мест (на Oracle во всяком случае)

О набежали. Я не против insert-ов (у меня они тоже есть). Я против велосипедов в борьбе с мифическими узкими местами. Первые три:

1. insert ... select sum ...

Нафиг мне не вперся и если это не узкое место, то я не знаю что такое узкое место. Лучше я сложу статистику в партиционированную табличку ОДИН раз (параллельно обновив баланс) чем буду insert-ить, агрегировать, снова insert-ить и delete-ить

2. индексы на табличке неагрегированных списаний

Как минимум на PK

3. FullScan-ы в п.1

Ибо по определению читать надо всю табличку, а кэшировать ее бесполезно в силу ее природы

4. Постоянные sum на запросе баланса

Одуреть можно

Dimitry Sibiryakov
легкоуправляемый оппонент...


мячты мячты :)
я вас уверяю, общение с вами доставляет мне не меньшее удовольствие

P.S. Приятно осозначать что есть на свете менее вменяемые люди чем ты сам

Dimitry Sibiryakov
Gluk (Kazan)
Лучше я сложу статистику в партиционированную табличку ОДИН
раз (параллельно обновив баланс) чем буду insert-ить, агрегировать,
снова insert-ить и delete-ить

Ага, первый приличный аргумент за всю дискуссию...


разьве не очевидно, что выполнение НЕНУЖНОЙ работы - узкое место ?

Dimitry Sibiryakov
Gluk (Kazan)2. индексы на табличке неагрегированных списаний

У оракула какие-то проблемы с индексами?


У Oracle с этим нет проблем, просто НЕНУЖНЫЕ накладные расходы (последняя соломинка способна сломать спину верблюду)

Dimitry Sibiryakov
Gluk (Kazan)3. FullScan-ы в п.1

Насколько я знаю, FullScan это единственное в чем оракул немерянно силен.


А НАСКОЛЬКО вы знаете Oracle ? Речь не о том, что ОТДЕЛЬНЫЕ личности не в состоянии уразуметь, что FullScan не всегда зло (это другая песня). FullScan-ы зло конкретно в ЭТОМ случае. Поскольку опять же совершенно излишни

Dimitry Sibiryakov Gluk (Kazan)4. Постоянные sum на запросе баланса

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


А я позволю себе усомниться, что данных по изменениям баланса за время жизни абонента будет МАЛО. А поскольку они заведомо будут плохо кластеризованы, дело опять же может запахнуть ненужными FullScan-ами или излишними изнасилованиями индексов

И на другой части весов корооооотенькая блокировка на малююююсеньком апдейте, происходящая довольно редко. По моему вполне достойная альтернатива вашей методе.

Впрочем не знаю к чему это приведет в огнептице, врать не буду. Но в Oracle ваше решение выглядит смешно и глупо

Dimitry Sibiryakov
Gluk (Kazan)Но в Oracle ваше решение выглядит смешно и глупо

Ну если оно выглядит так для оракула, то и магистры с ним. Надеюсь, мы
тут сказали достаточно слов чтобы топикстартер так вынес решение.
Posted via ActualForum NNTP Server 1.4

на том и порешим