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) Надо было сказать, что некоторые люди долго рабтающие ... Я тоже никогда не пользовался, а вот некие умы без оного не могуть.

← →
pasha_golub © (2005-07-27 11:56) [29]

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

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

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

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

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

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

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

← →
Johnmen © (2005-07-27 12:03) [30]

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

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

← →
pasha_golub © (2005-07-27 12:07) [31]

Johnmen © (27.07.05 12:03) [30]
Ну, совершенно ясно, что прав будет тот, кто быстрее клавиши топчет. :0) Я о другом...

← →
Johnmen © (2005-07-27 12:17) [32]

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

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

← →
pasha_golub © (2005-07-27 13:39) [33]

Johnmen © (27.07.05 12:17) [32]
Вообще-то, я имел в виду, не транзакции, а ситуации с отложенными изменениями.

← →
Digitman © (2005-07-27 13:45) [34]

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

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

> pasha_golub © (26.07.05 21:03)

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

← →
pasha_golub © (2005-07-27 13:48) [35]

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

← →
Sergey13 © (2005-07-27 14:03) [36]

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

← →
DiamondShark © (2005-07-27 14:28) [37]

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

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

← →
Андрей Жук © (2005-07-27 15:03) [38]

Потерянные изменения Потерянное изменение — классическая проблема баз данных. Если коротко, поте- рянное изменение возникает, когда происходят следующие события (в указанном по 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) такой защиты не обеспечивают. Как средства разработки, обеспечивающие защиту (за кадром), так и разработчики, использую щие другие средства (явно), должны применять один из двух описанных ниже методов блокирования.

← →
pasha_golub © (2005-07-27 18:45) [39]

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

← →
DiamondShark © (2005-07-27 21:19) [40]

> pasha_golub © (27.07.05 18:45) [39]

Прими это как откровение.

>Андрей Жук © (27.07.05 15:03) [38]
нефиг пользователю трогать чужую запись, вот и все
проблема с одновременным редактированием надумана на мой взгляд, при грамотном проектировании это не проблема

Том Кайт (а это цитата из него) думаю, больший спец по БД...

Том Кайт (а это цитата из него) думаю, больший спец по БД...

Проблемы множественного доступа не существует. Polevi © всё правильно сказал.

Одна из основных проблем при разработке многопользовательских приложений баз. данных — обеспечить одновременный доступ максимальному количеству пользователей при согласованном чтении и изменении данных каждым из них. Механизмы блокирова- ния и управления одновременным доступом, позволяющие решить эту проблему, являют- ся ключевыми в любой базе данных, и в СУБД Oracle они весьма эффективны.

Проблема такая существует, и проектировщик должен ее учитывать. Выбирая или оптимистическую, или пессимистическую блокировку.

Ой, вот что больше всего бесит, так это позиция: "Теоретики -- это, конечно, всё хорошо, но у нас тут особая практика".

Философия прапорщиков.
"Фиги думать? Трясти надо!"

добавляю от себя, игнорируя все вышесказанное ...

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

до сих пор живет и работает ... а при прямом коннекте все плакали от скорости работы, как только перевел под эту технологию все меня теперь очень любят :-) ...

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

...

Rule © (28.07.05 15:43) [52]
Жень, ведь для этих целей можно использовать и TClientDataSet. А тут речь о реализации данного механизма в потомках TDataset

← →
AxelBlack (2005-07-29 19:32) [55]

>To be or not to be?
однозначно to be
Проблемы одновременного редактирования одного и того же рекорда нет при грамотной проектировке и разработке приложений и при грамотном reconcile (без блокировки на сервере)

>Проблемы одновременного редактирования одного и того же рекорда нет

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

ЮЮ © (29.07.05 03:21) [54]
Таки да, мой дорогой друг. Но я, вообще-то, разговор веду о своем наследнике TDataSet... ;0) В котором кеширование не реализовано.

К чему и вопрос. Ибо для меня он чисто идеологический.

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