все возможноYocto писал(а):Такие вещи физически и не могут быть размещены за пределами досягаемости сервера базы.папа Карло писал(а):1. Размещение вещей ответственных за целостность и безопасность данных на клиенте не правильно.
Однако предоставление возможности управлять данным процессом со стороны клиента - вполне разумно.
Пример - isolation levels.
ты просто счастливый, подобных имплементаций не видел 
давай, ты технологию придумай, а мы посмотрим сколько народу ее пользовать начнетMarmot писал(а):Ага, представляю, но CPU,RAM, HDD сейчас дешевеют со страшной скоростью, так что не всё так плохо...папа Карло писал(а):ты оверхед и стоимость решения представляешь?Marmot писал(а):Так я не про то, что там народ предлагает, а про полный и глубокий versioning!
IMHO тогда компенсацию можно автоматизировать
Это может быть новый тип DBs, запатентовать что-ли
Ты всё ещё веришь, что что-то зависит от технологии???папа Карло писал(а):давай, ты технологию придумай, а мы посмотрим сколько народу ее пользовать начнетMarmot писал(а):Ага, представляю, но CPU,RAM, HDD сейчас дешевеют со страшной скоростью, так что не всё так плохо...папа Карло писал(а):ты оверхед и стоимость решения представляешь?Marmot писал(а):Так я не про то, что там народ предлагает, а про полный и глубокий versioning!
IMHO тогда компенсацию можно автоматизировать
Это может быть новый тип DBs, запатентовать что-ли
BTW, по CPU overhead будет небольшой,по IO тоже, а по HDD пофиг, винты сейчас большие.папа Карло писал(а):в этом то наука и есть, чтобы сделать минимальный оверхед для такой вещи и абсолютною незовисимость приложений от данной вещи.
Про Logminer -- подобные вещи есть во многих БД, называются только по-разному. Может быть Logminer более фичастая, но не в этом суть. Идея работы в том, чтобь делать селективный роллбэк с учетом зависимостей между транзакциями.MarkM писал(а):[trn]
V oracle eto uzhe est'. Nachinaja s 8i. Sm [/trn]LogMiner[trn]
Cherez LogMajner Orakl pokazyvaet izmenenija iz tranzakshn loga v vide SQL stejtmentov dvuh tipov, dlja nakata i dlja otkata.
Zavisimosti m-du tranzakcijami tam IMHO tozhe est'.
[/trn]
The Pooh писал(а):Было бы намного интереснее прочитать Введение (я уж не говорю про всю) для этой работы.
The Pooh писал(а): Так как после прочтения короткой анатации остается много вопросов. Ну а далее некоторые из вопросов:
1. Что есть плохая “транзакция”? Это наверное фундаментальный вопрос.
The Pooh писал(а):2. Что есть критерий селективности?
The Pooh писал(а):7. Далее, а что если этот лог зависимых транзакций …. Ээээ … переполниться… и DBA его слегка почистить.
The Pooh писал(а):8. Как и кто будет осуществлять управление откатами “плохих” транзакуций?
The Pooh писал(а):9. Для управления планируется использовать стандартный ЫЙД (SQL-99?). Или планируется расширить его синтаксис?
Ага, господин Xa-xa значит в авторах, а я сразу и не понял...Xa-xa писал(а):The Pooh писал(а):Было бы намного интереснее прочитать Введение (я уж не говорю про всю) для этой работы.
Скоро будет.
Xa-xa писал(а):The Pooh писал(а): Так как после прочтения короткой анатации остается много вопросов. Ну а далее некоторые из вопросов:
1. Что есть плохая “транзакция”? Это наверное фундаментальный вопрос.
Это определяется админом/пользователем.
Xa-xa писал(а):The Pooh писал(а):2. Что есть критерий селективности?
Выбираются те транзакции, которые зависят от начальной плохой транзакции. Транзакция T2 зависит от T1, если T2 читает данные, модифицированные T1.
Marmot писал(а):Ага, господин Xa-xa значит в авторах, а я сразу и не понял...Xa-xa писал(а): Скоро будет.
А такой уверенности нет. Просто нужна какая-то модель того, как транзакции могут зависеть друг от друга. Ничего лучшего того что есть без анализа семантики транзакций ИМХО сделать нельзя. Конечно, транзакция T1 может прочитать данные и передать их в другой процесс, который выполнит транзакцию T2 на основании этих данных. Понятно, что DBMS о такой связи никогда не узнает. На самом деле, перед отатом можно построить граф зависимостей между транзакциями и подредактировать его ручками...Marmot писал(а): А откуда такая уверенность что если Т2 прочитала данные модифицированные Т1, то Т2 модифицирует данные на основе этих самых данных модифицированных Т1.
Более того, Т2 может прочитать данные и передать их в Т3 которая вообще ничего не читала
А Т4 может про-updаte-ить данные модифицированные Т1 просто так, ничего не читая... надо ли её откатывать?
Ага, у нас здесь в Ванкувере китайцы тоже любят брать благозвучные имена, так что теперь понятно.Xa-xa писал(а):
Конечно, я Tzi-cker Chiueh.
Xa-xa писал(а):А такой уверенности нет. Просто нужна какая-то модель того, как транзакции могут зависеть друг от друга. Ничего лучшего того что есть без анализа семантики транзакций ИМХО сделать нельзя. Конечно, транзакция T1 может прочитать данные и передать их в другой процесс, который выполнит транзакцию T2 на основании этих данных. Понятно, что DBMS о такой связи никогда не узнает. На самом деле, перед отатом можно построить граф зависимостей между транзакциями и подредактировать его ручками...Marmot писал(а): А откуда такая уверенность что если Т2 прочитала данные модифицированные Т1, то Т2 модифицирует данные на основе этих самых данных модифицированных Т1.
Более того, Т2 может прочитать данные и передать их в Т3 которая вообще ничего не читала
А Т4 может про-updаte-ить данные модифицированные Т1 просто так, ничего не читая... надо ли её откатывать?
, плавали, знаем 
