Cached updates. To be or not to be?

← →
pasha_golub © (2005-07-26 21:03) [0]

Считаете ли вы порочным механизм кешированных апдейтов и почему?

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

Мое мнение: порочен. Ибо на клиенте отсутствует реальная картина.

← →
pasha_golub © (2005-07-26 21:09) [1]

И соответственно к механизму BDE, как к таковому.

← →
MiSHuTka (2005-07-26 21:12) [2]

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

← →
MiSHuTka (2005-07-26 21:13) [3]

Аболютно неприемлимая вещь... анахронизм ещё тот. На современных распределённых системах практически нереализуемо так, как было сделано у Борланда для локальных.

← →
Anatoly Podgoretsky © (2005-07-26 21:15) [4]

Механизм есть, можно не пользоваться, я никогда не использовал, поскольку нужна реальная картина в базе.

← →
pasha_golub © (2005-07-26 21:16) [5]

Anatoly Podgoretsky © (26.07.05 21:15) [4]
Механизм есть. С этим не поспоришь. Интересует вопрос, а не промахнулся ли Борланд дав этому механизму жизнь на многопользовательских системах?

← →
Anatoly Podgoretsky © (2005-07-26 21:23) [6]

Не проиахнулся, что есть подобное во многих других вещах.
К этому можно отнестись двояко

1. отсоединеный датасет, отложеная запись
2. использование, как попытка исправить кривизну с нередактируемыми наборами.

Ничто этого меня не прельщает.

← →
Torry © (2005-07-26 21:29) [7]

Паша, упаси моральный кодекс!!!!

Если еще кого-то, кто упомянет про CachedUpdates увижу, давить буду страшно :-)

← →
Anatoly Podgoretsky © (2005-07-26 21:44) [8]

Torry © (26.07.05 21:29) [7]
Чем тебя оно так достало?

← →
Torry © (2005-07-26 21:52) [9]

Толя, все очень просто: мы выпуcкаем DAC for MySL и PostgresDAC. До этого ыя много лет работал с Btrieve и просто устал от, извиняюсь, но так и есть, от ламерских вопросов по поводу CachedUpdates.

Ну если люди не понимают банальных вещей, что делать? :-))

← →
Anatoly Podgoretsky © (2005-07-26 22:31) [10]

Понял, а то мне показалось, что CachedUpdates достал, а все много проще :-)

← →
Torry © (2005-07-26 22:33) [11]

Ну вот, и поняли друг друга :-)

← →
Anatoly Podgoretsky © (2005-07-26 22:40) [12]

Anatoly Podgoretsky © (26.07.05 21:23) [6]
Забыл указать еще одно из частных применений, это иммитация транзакций.
Хотя основное назначение указано в самом названии.

← →
pasha_golub © (2005-07-26 23:22) [13]

Однако, иммитация не есть сам секс....

Это, я в продолжение дисскусии...

============
Смысл таков:
Люди долгое время работающие с BDE жаждут cached updates. В свою очередь, сама практика использования этого механизма в end-user проектах, приводит к краху самой идеологии многопользовательской системы.

Хочу услышать глас программистов. Что есть "кешированные изменения" (на клиенте!!!!) для жизни всего цикла?

← →
Anatoly Podgoretsky © (2005-07-26 23:44) [14]

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

← →
DiamondShark © (2005-07-27 00:30) [15]

> Мое мнение: порочен. Ибо на клиенте отсутствует реальная
> картина.

В многопользовательской системе она никогда не будет присутствовать.

← →
Petr V. Abramov © (2005-07-27 02:24) [16]

to be!

← →
Petr V. Abramov © (2005-07-27 02:26) [17]

> И соответственно к механизму BDE, как к таковому.
Must die!

← →
Petr V. Abramov © (2005-07-27 02:36) [18]

В любом случае при самых прогрессывных на сегодня технологиях client/server так и рабтает. Просто доброе BDE берет на себя "свю заботу" о синхронизации датасета с базой на сервере. Доброта заканчиватеся, когда, Requqestlive ошибочно выставлено в true. Это, конечно, редко бывает, оно лучше перебдит, чем недобдит. А если в false? А юзайте ttable или Pidarox SQL, там все нормально будет.
Откуда BDE-то с TTable пошло. От него, родимого. А все остальное - "а чтоб работать с таблицей Oracle, как Pidarox`овской". Кроссплатформенность, аданака. 10 лет назад модно было, благодаря чему мы уже на D<целых 2005> кодим

← →
ЮЮ © (2005-07-27 02:59) [19]

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

← →
Anatoly Podgoretsky © (2005-07-27 08:49) [20]

ЮЮ © (27.07.05 02:59) [19]
Не передергивай.
Речь совсем про другое, реальная картина не на клиенте, а в базе, изменил запись - записал, доступна другим клиентам.
А иммитация транзакций это другое, если нужна то да, но она не шарантирует " когда часть записей соответствует истине, а часть - нет", при кешированых апдейтах не будет истины.
Иммитацию часто использую не для соответсвия истине в базе, а для возможности отмены изменений, поскольку нет механизма в файл-серверных базах.
Часто работа с кешироваными апдейтами выглядит так, целый день человек пишет, а потом раз в день скидывает в базу.

Наиболее часто используют для создания редактируемого набора, ну не умеют делать по другому.

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

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

← →
Виталий Панасенко (2005-07-27 09:59) [21]

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

А как же тогда dbExpress ? это там как раз и хвалят(я о ректировании НД БЕЗ реального внесения изменений в БД до определенного момента (типа ApplyUpdates ?) ) ? принцип то почти такой же, только без БДЕ.. может, конечно, "гоню"..:-)

← →
Johnmen © (2005-07-27 10:11) [22]

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

← →
Ega23 © (2005-07-27 10:20) [23]

2 pasha_golub © (26.07.05 23:22) [13]
============
Смысл таков:
Люди долгое время работающие с BDE жаждут cached updates.

Паш, иди нафик, я 4 года с BDE работал, ни разу Updates не использовал

← →
ksa2002 (2005-07-27 10:33) [24]

Виталий Панасенко (27.07.05 09:59) [21]
Вроде там транзакции а не кэширование как токовое, сие вроде как разные вещи.

← →
Виталий Панасенко (2005-07-27 10:37) [25]

> ksa2002 (27.07.05 10:33) [24]
> Виталий Панасенко (27.07.05 09:59) [21]
> Вроде там транзакции а не кэширование как токовое, сие
> вроде как разные вещи.

Да, но принцип то тот же - данные (запись за записью) правятся на клиенте БЕЗ изменений (пусть и не подтвержденных) в БД.. а затем уже пишутся после "окончательного решения"...

← →
ksa2002 (2005-07-27 10:39) [26]

кэширование хранит данные отедельно
а транзакции уже в базе

← →
Anatoly Podgoretsky © (2005-07-27 10:44) [27]

Виталий Панасенко (27.07.05 10:37) [25]
Это только внешне похоже. Кроме того при транзакции данные правятся на сервере, а не на клиенте и вносятся (применяются) сразу все даже без кратковременного нарушения целостности, в отличии от кеширования, где определенный момент времени данные в базе не консистентные. И боюсь, что если в середине применения кешированых данных возникнет ошибка, то в базе будет мусор.
Не стоит ставить знак равенства между отложеной записью и транзакций, это из разных опер.

← →
pasha_golub © (2005-07-27 11:50) [28]

Эта, действительно, транзакции тут не тем местом, как бы.

Транзакция - это прежде всего атомарность. А кешированные записи, это пардон, совсем не оттуда.

Ega23 © (27.07.05 10:20) [23]
Фууух, слава яйцам. :0) Надо было сказать, что некоторые люди долго рабтающие ... Я тоже никогда не пользовался, а вот некие умы без оного не могуть.

Виталий Панасенко (27.07.05 10:37) [25]

А представь такой вот момент.

Имеем Клиент1 и Клиент2. Редактируют один и тот же набор.

Клиент1 правит запись, в это же самое время Клиент2 ее удаляет.

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

В некоторый момент они решают скинуть изменения на сервер. В середине процесса возникает ошибка. Как быть? Отменять одну операцию? Отменять все операции? Игнорировать?

А если от этой удаленно-модифицированной записи зависят другие данные?

>pasha_golub © (27.07.05 11:56) [29]

Надеюсь понятно, что прав будет только один из двух ?
Он и добьётся желаемого. Другой идёт пить пиво...

>pasha_golub © (27.07.05 12:07) [31]
>Я о другом...

А о чём ?
Механизм разруливания конкурирующих транзакий хорошо описан в массе литературы.

> Johnmen © (27.07.05 10:11) [22]

Так точно, сэр !)

> pasha_golub © (26.07.05 21:03)

по сабжу я солидарен с Johnmen © (27.07.05 10:11) [22]

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

Губит людей не пиво. Губит людей вода. 8-)

> Я то про другое, что механизм этот развращает неокрепшие
> умы.

Наоборот. Развращает имитация прямой работы с таблицами, т.е. как раз немедленные обновления.
Это идеология чисто локально-файловых баз.

Потерянные изменения Потерянное изменение — классическая проблема баз данных. Если коротко, поте- рянное изменение возникает, когда происходят следующие события (в указанном по 1. Пользователь 1 выбирает (запрашивает) строку данных. 2. Пользователь 2 выбирает ту же строку. 3. Пользователь 1 изменяет строку, обновляет базу данных и фиксирует изменение. 4. Пользователь 2 изменяет строку, обновляет базу данных и фиксирует изменение. Это называется потерянным изменением, поскольку все сделанные на шаге 3 изме- нения будут потеряны. Рассмотрим, например, окно редактирования информации о сотруднике, позволяющее изменить адрес, номер рабочего телефона и т.д. Само приложение — очень простое: небольшое окно поиска со списком сотрудников и возможность получить детальную информацию о каждом сотруднике. Проще некуда. Так что пишем приложение, не выполняющее никакого блокирования, — только простые операторы SELECT и UPDATE. Итак, пользователь (пользователь 1) переходит к окну редактирования, изменяет там адрес, щелкает на кнопке Save и получает подтверждение успешного обновления. Все отлично, кроме того, что, проверяя на следующий день эту запись, чтобы послать сотруднику налоговую декларацию, пользователь 1 увидит в ней старый адрес. Как это могло случиться? К сожалению, очень просто: другой пользователь (пользователь 2) запросил ту же запись за 5 минут до того, как к ней обратился пользователь 1, и у него на экране отображались старые данные. Пользователь 1 запросил данные, изменил их, получил подтверждение изменения и даже выполнил повторный запрос, чтобы увидеть эти изменения. Однако затем пользователь 2 изменил поле номера рабочего телефона и щелкнул на кнопке сохранения, не зная, что переписал старые данные поверх внесенных пользователем 1 изменений адреса! Так может случиться потому, что разработчик приложения предпочел обновлять сразу все столбцы, а не разбираться, какой именно столбец был изменен, и написал программу так, что при изменении одного из полей обновляются все. Обратите внимание, что для потери изменений пользователям 1 и 2 вовсе не обязательно работать с записью одновременно. Нужно, чтобы они работали с ней примерно в одно и то же время. Эта проблема баз данных проявляется постоянно, когда разработчики графических интерфейсов, не имеющие достаточного опыта работы с базами данных, получают задание создать приложение для базы данных. Они получают общее представление об операторах SELECT, INSERT, UPDATE и DELETE и начинают писать программы. Когда получившееся в результате приложение ведет себя, как описано выше, пользователи полностью перестают ему доверять, особенно потому что подобные результаты кажутся случайными и спорадическими и абсолютно невоспроизводимы в управляемой среде тестирования (что приводит разработчика к мысли, что это, возможно, ошибка пользователя). Многие инструментальные средства, например Oracle Forms, автоматически защи- щают разработчиков от таких ситуаций, проверяя, не изменилась ли запись с момента запроса и заблокирована ли перед началом изменений. Но другие средства разработки (и обычные программы на языке VB или Java) такой защиты не обеспечивают. Как средства разработки, обеспечивающие защиту (за кадром), так и разработчики, использую щие другие средства (явно), должны применять один из двух описанных ниже методов блокирования.

DiamondShark © (27.07.05 14:28) [37]
Ну, нифига ж себе. Эта, даже не знаю, что ответить, но возмущен до глубины души... :0)

Cached updates. To be or not to be? Найти похожие ветки