Что-то тема не пользуется популярностью, хотя концептульные недоработки каше налицо - нет ни версионности ни реализации снапшота ни repeatable read, которые есть в большинстве популярных РСУБД :(

/topic/846423&pg=1

а как тогда отчеты-то строим, господа? в расчете на ночные калькуляции?

Блок А.Н.,

чему удивляетесь? разве Вы не согласны что в отсутствии нужного уровня изоляции транзакций формировать консистентные отчеты можно не в 100% случаев и лишь со множеством "если"

для многопользовательской СУБД управление конкурирующими транзакциями - основная задача.
в том числе на системном уровне должно быть решены вопросы с фантомами.
сейчас максимум из того что должно быть есть только read_commited

Блок А.Н.Могу вам сказать, что вашу систему проектировал тот, кто не умеет этого делать, и теперь вы негодуете, что не пришел добрый дядя и не сделал за вас всю работу "на системном уровне".


в отсутствие нормальных аргументов переход на личности порочная практика некоторых авторов в форумах

при чем здесь дядя? почитайте начало топика - при чем здесь архитектура приложения? вопрос в том что без системно поддерживаемого СУБД снапшота или повторяемого чтения Вы принципиально в приложении не сможете обеспечить повторяемое чтение. Именно поэтому любой отчет априори неконсистентен. Да, в _некоторых_ случаях (в Вашей системе например ночью) может случиться так что апдейтов нет и отчет выдаст то что нужно, но в общем случае это не так.

Блок А.Н.Мне, например, совершенно не нужно то, о чем вы говорите. И хотя наша система довольно таки многопользовательская, блокировки в ней используются в очень небольшом количестве мест.


а где я упоминаю блокировки?

Блок А.Н.То же касается и транзакций, мало того многие программы с транзакциями мы иногда переписывали на код без транзакций либо с минимальным их количеством.

Видимо Вы не ведаете что творите. Каким образом Вы обеспечиваете атомарность изменений в Вашей системе?

Блок А.Н.Rus000 без системно поддерживаемого СУБД снапшота или повторяемого чтения Вы принципиально в приложении не сможете обеспечить повторяемое чтение. Да нет, вы путаете. Это Вы не можете ;-)


хех, для начала "давайте обсуждать вкус креветок с теми кто их ел" (c)

что ж раз вызвались, покажите здесь пример _прикладного уровня_, обеспечивающий повторяемой чтение. Надеюсь не нужно напоминать требование к этому уровню изоляции?

Проще разобраться с ситуацией, когда падающий процесс говорит "пиу", и оставляет все как было.
Значительная часть операций уже сама по себе атомарна, либо атомарность не критична.


это просто перл :)

классический пример: со счета А делаем перевод денег на счет Б. Со счета А сняли, записать на Б не успели и процесс "пиу" (c). Транзакции нет - что делать-то будете?

Для примера, нужно разнести макет на 100000 записей.
[skip]
Транзакции остаются только на самом нижнем уровне, который являятся критичным.

и что показывает этот пример? вернитесь к repeatable read

что ж раз вызвались, покажите здесь пример _прикладного уровня_, обеспечивающий повторяемой чтение. Надеюсь не нужно напоминать требование к этому уровню изоляции?


ждем примера, потом продолжим дискуссию про микрооперации

Блок А.Н.Вы опять все путаете. Это у вас проблемы, и вам нужна помощь.
А с подходом, что вам кто-то что-то должен, вы далеко не уедете.

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

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

Блок А.Н.Rus000 без системно поддерживаемого СУБД снапшота или повторяемого чтения Вы принципиально в приложении не сможете обеспечить повторяемое чтение. Да нет, вы путаете. Это Вы не можете ;-)


Сказали А говорите Б - ждем, ждем.

Блок А.Н.На слабо пытаетесь взять? Чтобы я пытаясь что-то вам доказать, делал за вас работу?
Нее ... :-)


я не прошу делать за меня работу, а прошу показать ЛЮБОЙ мифический пример который бы показывал свойства повторяемого чтения.
Примера я не вижу здесь, значит делаю вывод что этого сделать нельзя. Ну или точнее вы его сделать не можете, несмотря на бахвальство выше.

Слив засчитан, как говорится. Что и требовалось доказать про концептульные пробелы каше.

Попытайтесь понять, что нет некого мистического "системного уровня". Все зависит от того, куда вас пускает производитель субд и что он за вас делает.
Представьте, что вы разработчик оракла. Вот что бы вы сделали? Вот нужно сделать инсерт, чтобы его не видел другой процесс, вот апдейт нужно делать, но для разных процессов хранить обе копии. Представьте, что нет никаких транзакций. Ну? Это ведь не сложно.


поверьте, это сложно. возьмите пару серьезных книжек по транзакционной обработке и офигеете от теоретических посылок, я уже не говорю о реализации.

И все-таки, не нужно экстраполировать ваши проблемы на всех. И не думайте, что если вы отчетык берете с тени, то все это делают.

Если Вы этого не понимаете то это не значит что этой проблемы в СУБД не существует. Я утверждаю что есть нерешенная в каше задача обеспечения transaction level consistency.
Именно поэтому приходится лепить коленочные "конструкторы" которые и отдаленно не могут приблизится по степени проработки системных решений, которые есть в большинстве популярных СУБД, ДАЖЕ в FB, которая не позиционируется как промышленная. И из-за отсутствия таких системных механизмов прикладные разработчики и как следствие заказчики получают непонятно какие отчеты.
Вот в чем печаль, коллега.

Блок А.Н.На прикладном уровне гораздо все гораздо проще, вам не нужно писать универсальный компилятор и процессор запросов, учитывающий все эти моменты. Вам всего лишь нужно хранить данные так, чтобы самому в них не запутаться.
Т.е. все версии данных, если они имеют какое-то значение, должны храниться. К каждой версии данных должна быть прикреплена метка времени. В большинстве случаев этого будет достаточно, и это просто в реализации.


это проще для систем которые только в стадии проектирования. Но не применимо для систем архитектура уже сложилась за годы эксплуатации и доработки. Если бы каше представляло возможность создания снапшотов и повторяемого чтения, решение было бы универсально для любых приложений причем _без переделки_, соответственно сохранение ранее вложенных в разработку программы инвестиций.

Если вы используете длительные транзакции, то все усложняется (поэтому я избегаю длительных транзакций)


это понятно, вопрос не в этом, а в том, что для обеспечения консистентности вам _придется_ использовать длинную транзакцию для обертывания всего отчета, чтобы он посчитался корректно. По крайней мере так делается в оракле, ms sql, sybase и FB.

С учетом того, что в каше нет консистентности на уровне транзакций, делать длинные транзакции не имеет смысла.

В случае с одним уровнем транзакции нужно будет держать метки нахождения в транзакции и временные метки выхода из транзакций, что уже на грани изврата, а в случае многоуровневых транзакций и вовсе превращается в хрен знает что.

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