|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Troglodit, Смысл идеи - убрать лишние записи периодически схлопывая дельты, это один из способов оптимизировать скорость выполнения запроса для подсчета агрегата, имеет смысл, когда записей по агрегируемой группе очень очень много, а запрос выполняется очень часто. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 21:59 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDev Troglodit, Смысл идеи - убрать лишние записи периодически схлопывая дельты, это один из способов оптимизировать скорость выполнения запроса для подсчета агрегата, имеет смысл, когда записей по агрегируемой группе очень очень много, а запрос выполняется очень часто. Это я понял, но можно и без схлопывания, тупо мержить запись. В моем предложении, когда нам консистентность на 100% не нужна,блокировок на мерж записей ПОСЛЕ коммита не будет. Просто реализация - это отказ от ACID. Решение: а давайте возьмем и выбросим все эти транзакции на помойку. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 22:04 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Troglodit, У таблицы расчета агрегата смысл только один, если записей по агрегируемой группе миллион, то в таблице с рассчитанным агрегатом будет всего одна, оперативные изменения будут входить в нее в виде дельт, которые будут периодически процедурой схлопываться в одну, таким образом вместо суммирования по миллиону записей, суммирование будет идти по одной записи с готовой суммой плюс еще не схлопнутые дельты. Без процедуры схлопывания дельт выигрыша в скорости нет и смысла в такой конструкции также нет. Подобная конструкция ткже усложняет дальнейшую поддержку системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 22:17 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDev Troglodit, У таблицы расчета агрегата смысл только один, если записей по агрегируемой группе миллион, то в таблице с рассчитанным агрегатом будет всего одна, оперативные изменения будут входить в нее в виде дельт, которые будут периодически процедурой схлопываться в одну, таким образом вместо суммирования по миллиону записей, суммирование будет идти по одной записи с готовой суммой плюс еще не схлопнутые дельты. Без процедуры схлопывания дельт выигрыша в скорости нет и смысла в такой конструкции также нет. Подобная конструкция ткже усложняет дальнейшую поддержку системы. Да это все понятно я, я к тому что вместо 3х позиций Пети,Васи,Вани по одному агрегату как предлагали выше, должно схлопываться(мержиться) в ОДНУ запись, и тогда на ни вью с суммой по агрегату, ни периодическая чистка а перед этим агрегация, не нужна. Т.е. вместо В агрегате хранится "на складе 100 яблок". Пришёл Вася, записал "я продал 30 яблок", В агрегате хранится "на складе 70 яблок" Пришёл Петя, записал "я продал 20 яблок", В агрегате храниться "на складе 50 яблок" Никаких дополнительных строк по яблокам, мы просто меняем остаток по яблокам. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 23:15 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDev Не очень хороший пример, основываясь на предположении без подтверждения блокировать ресурс не очень хорошая практика. Говорить "ой, извините, мы не можем выполнить то, что сами же вам и предложили, а вы вдруг взяли и согласились" - практика ещё хуже. Пример, конечно, нарочитый и упрощённый, но несёт именно то, что я хотел изложить в свете слов топикстартера - "сложный агрегат" (расписание кто когда где может быть занят) считается на ходу и может привести к предупреждениям и решению приостановить или отменить вроде бы выдвинутый документ. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2019, 23:33 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Troglodit, При изменении одной и той же строки мы имеем сериализацию (блокировки), именно поэтому и было предложено хранить дельты В агрегате хранится "на складе 100 яблок". Пришёл Вася, записал "я продал 30 яблок", В агрегате хранится "на складе -30 яблок" Пришёл Петя, записал "я продал 20 яблок", В агрегате храниться "на складе -20 яблок" сумма по таблице агрегата даст 50. Отрабатывает периодическая процедура и остается одна строка В агрегате хранится "на складе 50 яблок". Пользователи могут только добавлять строки дельт, процедура меняет строку с итоговым агрегатом и удаляет строки, уже учтенные в итоговом агрегате, при этом изменения одних и тех же строк разными пользователями нет и процедура с ними тоже не пересекается. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 01:19 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer Говорить "ой, извините, мы не можем выполнить то, что сами же вам и предложили, а вы вдруг взяли и согласились" - практика ещё хуже. Пример, конечно, нарочитый и упрощённый, но несёт именно то, что я хотел изложить в свете слов топикстартера - "сложный агрегат" (расписание кто когда где может быть занят) считается на ходу и может привести к предупреждениям и решению приостановить или отменить вроде бы выдвинутый документ. Пример не жизненный и неудачный, поскольку в результате труппа остается без работы, а менеджер идет на улицу. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 01:26 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
iOracleDev Troglodit, При изменении одной и той же строки мы имеем сериализацию (блокировки), именно поэтому и было предложено хранить дельты В агрегате хранится "на складе 100 яблок". Пришёл Вася, записал "я продал 30 яблок", В агрегате хранится "на складе -30 яблок" Пришёл Петя, записал "я продал 20 яблок", В агрегате храниться "на складе -20 яблок" сумма по таблице агрегата даст 50. Отрабатывает периодическая процедура и остается одна строка В агрегате хранится "на складе 50 яблок". Пользователи могут только добавлять строки дельт, процедура меняет строку с итоговым агрегатом и удаляет строки, уже учтенные в итоговом агрегате, при этом изменения одних и тех же строк разными пользователями нет и процедура с ними тоже не пересекается. Блокировки будут безусловно (стандартные, но не те долгие, которые мы обсуждаем), но в нашем случае если использовать event'ы там все будет стандартно. Т.е. начало изменения агрегата будет происходить уже ПОСЛЕ коммита долгой транзакции, если будет откат вызов event'a не произойдет. Да мы жертвуем консистентностью, появляется вопрос, что делать если не смогли обработать event, но мне кажется это проще вариант с агрегированием агрегата во вью и периодическая чистка. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 09:05 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
па сабжу: По возможности сделать все возможные проверки до проведения. То, что нельзя проверить: пробуем провести документ с параметром " реагировать на ошибку ХХ". Если ошибка, то откатываем изменения и выводим соотв. сообщение. Если юзер подтверждает проведение с ошибкой, то снова проводить с параметром " Не реагировать на ошибку ХХ". ... |
|||
:
Нравится:
Не нравится:
|
|||
09.12.2019, 17:10 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
Разве задача не стара как мир ? Как считать остатки товара на складе если пользователей 1000 и все продают с этого склада. Вариант 1. Отрицательные остатки разрешены - фиксируем совершенные бизнес-операции, разбираемся потом. Вариант 2. Отрицательные остатки не разрешены. Создаем стек транзакций, каждая транзакция считает возможность проведения операции. Если возможности нет - пользователю возвращается отрицательный результат и берется следующая транзакция их стека. Вы хотите придумать вариант 3? Зачем ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 12:03 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
L_argo Если юзер подтверждает проведение с ошибкой, то снова проводить с параметром " Не реагировать на ошибку ХХ". Проблема этого подхода в том, что между двумя последовательными вызовами с базой параллельно работают и другие пользователи. Поэтому вполне может случиться так, что после "проведения с ошибкой" возникнет уже не ошибка XX, а ошибка YY (либо ошибка XX, но с другими числовыми значениями, которые пользователь уже не подтвердил бы). ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 14:00 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
во блин, неужто непонятно что бабу можно одновременно только в несколько независимых дыр это максимум до чего дошел порнушный прогресс а так по очереди (и по хорошему - если согласна) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 14:14 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer L_argo Если юзер подтверждает проведение с ошибкой, то снова проводить с параметром " Не реагировать на ошибку ХХ". Проблема этого подхода в том, что между двумя последовательными вызовами с базой параллельно работают и другие пользователи. Поэтому вполне может случиться так, что после "проведения с ошибкой" возникнет уже не ошибка XX, а ошибка YY (либо ошибка XX, но с другими числовыми значениями, которые пользователь уже не подтвердил бы). Большинство обсуждаемых кейсов в большей степени надуманы. ХРРРРР!!! сказала пила..... Ааа пля, сказали рабочие (с) анек ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 14:36 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
L_argo Если не установлен игнор ошибки YY, то будет откат и другое сообщение. :) О том и речь. Такой процесс склонен доходить до зашкаливающей степени идиотизма. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 14:40 |
|
Диалог с пользователем в транзакции
|
|||
---|---|---|---|
#18+
softwarer L_argo Если не установлен игнор ошибки YY, то будет откат и другое сообщение. :) О том и речь. Такой процесс склонен доходить до зашкаливающей степени идиотизма. Если код правильно написан, то сообщение расскажет о всех ошибках, а не только о первой. Поэтапное появление ошибок вещь неприятная, но будет редко встречаться. А как по другому, если нужно знать решение пользователя ? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.12.2019, 17:33 |
|
|
start [/forum/topic.php?fid=32&msg=39902056&tid=1539889]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
others: | 239ms |
total: | 407ms |
0 / 0 |