lazy foxПотому, что женщина нарисована не рядом, а на 5см северо-западнее одной из вершин треугольника.

Ну и что? Если имеется в виду что теперь при перемещении треугольника женщина так же должна переместиться, или что при удалении треугольника женщина так же должна удалиться, то это значит что к треугольнику ДОБАВЛЕНА СВЯЗЬ с женщиной. То есть параметры треугольника изменились другим пользователем и в откате опять же будет отказано.

Alex.CzechА это означает что операция "отката" треугольника ничем не будет отличаться от его удаления - ну и зачем тогда ее нужно реализовывать отдельно ?

Откат "удаления треугольника" ничем не будет отличаться от его перерисовки заново и т.п. Откат "удаления параграфа" в Ворде эквивалентно "заново его напечатать". Можно ли обойтись без откатов? Конечно можно. Зачем же тогда его везде, где возможно, реализуют?

tygraА задача СУБД - чтобы всегда в любой момент времени (закоммиченные) данные были достоверные. Интересно, как сюда можно воткнуть откат транзакций, причем не просто откат всего состояния назад, а откат выборочно. Тогда у вас в БД будет даже не бардак - хаос. И потом все бы орали: да эта СУБД дрянь, данные пропадают, не понять чего творится, вчера было - сегодня нет, все перепутано..... И опять какая-нибудь MS была бы виновата.....


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

tygra
Пора закрыть тему - из пустого в порожнее переливаем.
И если уж хочется - открыть новую тему: как в системе сделать произвольный откат произведенных действий - методы решения.

-- Tygra's --

Я то знаю как это сделать. Меня интересует насколько эта функциональность может быть востребована.

lazy fox serg99 lazy foxПотому, что женщина нарисована не рядом, а на 5см северо-западнее одной из вершин треугольника.

Ну и что? Если имеется в виду что теперь при перемещении треугольника женщина так же должна переместиться, или что при удалении треугольника женщина так же должна удалиться, то это значит что к треугольнику ДОБАВЛЕНА СВЯЗЬ с женщиной. То есть параметры треугольника изменились другим пользователем и в откате опять же будет отказано.

Никаких связей не добавлено ибо незакоммитчено...

Если женщина не закоммичена, то значит ее в базе нет и треугольник можно откатить. Зато тот кто ПОСЛЕ ЭТОГО будет коммитить женщину и ее связь с УЖЕ не существующим треугольником получит отлуп.

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

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

Я нигде не упоминал однопользовательские системы. Я упоминал откат транзакций в контексте одного пользователя, но в многопользовательской системе.

Естественно существуют так называемые закрытые периоды или неоткатываемые транзакции, когда результаты действий пользователя вышли за пределы информационной системы (отчеты переданы в фискальные органы, банкомат уже выдал деньги, закрыт операционный день и т.п.). Здесь что бы что то изменить нужно либо выкрасть отчеты из налоговой инспекции, либо сторнировать проводки в следующем балансе, а тот кто сидит в банкомате должен догнать и отобрать деньги у клиента :-). То есть исправление ошибок в этих случаях так же требует выхода за пределы информационной системы и подключения к этому организационно-административных ресурсов.

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

Не пойму, что Вам запрещает реализовать Вам систему с треугольником, женщиной и откатом удалений на СУБД? Переходите на уровень выше. Понимаете о чем я? Как в стеке протокола TCP/IP, один уровень инкапсулируется в другой! СУБД не обязана поддерживать все прихоти пользователей сама, она должна предоставлять только платформу для организации хранения и доступа. Вся логика системы закладывается в БД ее разработчиком, а не разработчиком СУБД.

ОС Windows то же предоставляет платформу. Берем ассемблер и работаем напрямую через WIN32 API, реализуя прикладную логику. Но всех тянет почему то на готовенькое типа С и Forms.

Вам нужно откатывать избранные транзакции? А кто Вам сказал, что эти транзакции должны быть транзакциями с СУБД?

А с кем они еще могут быть транзакциями? Действие пользователя превращается в запрос приложения к СУБД, который выполняется или невыполняется этой самой СУБД как единое целое.

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

Странные у Вас определения транзакций. Если все это транзакции, то значит можно сказать "откат нажатия кнопки" или "откат отсылки команды". Но что это значит я представить не могу. Разве что длинная рука приложения лезет в кабель, хватает отосланный только что пакет данных и засовывает его обратно в буфер контроллера Ethernet.

Пример реализации механизма - оператор удаляет, а в БД НЕ УДАЛЕНИЕ, а пометка. Вот и все, новые объекты можно цеплять только к тем, которые не помечены, если захочешь грохнуть что-то старое, то оно не грохнется, если к нему уже что-то подцеплено. Ссылочную целостность обеспечивает СУБД.

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

В очередной раз сталкиваюсь на этом форуме с людьми, которые не представляют себе процессов в системе (как на уровне СУБД, так и на прикладном уровне) и не могут разделить у себя в голове эти понятия. Заодно и разделите понятия СУБД и своей прикладной системы.

Куда уж нам с суконным рылом в сермяжный ряд.

Если по ТЗ система должна позволять это, то надо реализовывать, если нет - то нет. Система должна делать только то, что написано в ТЗ. Все остальное в лог-файле.

Да, да - все в сад. И заодно самостоятельно напишите систему репликации БД, потому что лог-файл предоставляет для нее достаточную платформу.

Читайте Дейта, вообщем.

Если он писал что то про откат закоммиченных транзакций, то дайте пожалуйста ссылку. Надеюсь это не бессмысленное упоминание первоисточников в стиле "читайте материалы ХХV Съезда КПСС".

lazy fox Да, кстати, откуда ваш сервер знает что-то о связях объектов? Допустим, мой клиент смотрит на монитор и кладет в БД строчку 'баба сидит на треугольнике', а ваш клиент замечательно воспроизводит написанное. Как из этой строчки сервер вытащит связь двух объектов?

А я положу в БД строчку `компания купила компьютер`. Как Ваш сервер из этой строчки вытащит связь двух объектов? И почему эта связь должна вытаскиваться из строчки? И куда в БД я должен положить эту строчку, что бы это чудо произошло?

lazy foxНет, это я вас спрашиваю: как мне теперь определять связи между объектами, хранить эти связи в вашей БД, чтобы вы имели возможность блокировать произвольные откаты с учетом семантики связей и что такое вообще "связь между объектами" с точки зрения ООП?

Я не очень понимаю причем здесь ООП и вообще не хотелось бы вдаваться в подробности реализации. Представим что такая функциональность (типа savepoints в Workspace, но "прозрачно" для пользователя) реализована. То есть
1) Администратор может откатить всех в любую точку в прошлом (в рамках задаваемого временнОго окна).
2) Конкретный пользователь может при определенных условиях откатить "свои" транзакции обратным порядком или даже выборочно откатить прошлые транзакции не трогая последующие.

Вопрос был в том насколько такая возможность будет востребована программистами БД.

vybegalloЕще раз поясняю : при выборочном откате транзакций в больших системах бардак неизбежен.
Оператор удалил клиента. Отчет №1 заполнил таблицу №1 итогами по клиентам. Отчет №2, используя первую таблицу, заполнил таблицы №2 и 3.
И так далее.
Теперь малой кровью восстановить клиента не получится - с учетом того, никто не представляет всей системы. Это можно сделать либо тщательно распутывая каждую связь, либо восстановив систему на момент непосредственно предшествующий удалению.

Вопрос в том можно ли в принципе удалить клиента по логике приложения? Допустим можно. Можно ли ввести нового клиента? Разумеется. Если приложение корректно отрабатает ситуацию когда я вручную удаляю клиента, а затем вручную добавляю клиента эквивалентного удаленному, то не вижу основы для бардака. Если какие то отчеты должны соответствовать первичным данным, то они периодически перезапускаются. Если соответствие нужно в реальном времени, то отчеты запускаются по триггерам по изменению первичных данных. Если по клиенту скажем уже прошли торговые операции, то приложение с самого начала просто запретит удаление такого клиента, иначе эти операции "повиснут". То есть при выборочном откате транзакций приложения разрешается откат только тех транзакций которые не "конфликтуют" с транзакциями других приложений или со своими более поздними транзакциями.

iLLerУже как два года назад написал. И годится для любой СУБД, поддерживающей триггеры.)))

Я всегда говорил, что не перевелись еще таланты на земле Русской.

lazy foxПо второму пункту: вы _не_знаете_ этих "определенных условий". Эти условия определяются логикой _моего_ приложения. А поскольку я с хорошей вероятностью запарюсь вам объяснять, что баба присела на треугольник просто покурить, а потом встанет и уйдет, _сама_ без транзакций уйдет, у меня так написано - встала и ушла, а в базе есть, а мне пох, только на клиенте ушла... Так вот по этой причине не будет такая возможность востребована программистами БД ))

Вы главное не волнуйтесь. Если баба от клиента ушла, то и бог с ней. В базе то она еще осталась :-).

Проблема правда в том что за соседним компьютером в Вашем же приложении баба например взяла и легла на треугольник поспать. Возникает вопрос "что на самом деле делает баба - вообще ушла (клиент1), спит (клиент2) или курит (БД)?". Клиента которому безразлично что происходит в базе, я не могу отнести к программе БД, а программиста который такие клиенты пишет - к программистам БД.