Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Cached updates. To be or not to be?

Страницы: < 1 2 3 >
pasha_golub © (2005-07-26 21:03:00)
Считаете ли вы порочным механизм кешированных апдейтов и почему?

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

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

DiamondShark (2005-07-27 14:28:00) [21]

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

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

Sergey13 (2005-07-27 14:03:00) [22]
Губит людей не пиво. Губит людей вода. 8-)

pasha_golub (2005-07-27 13:48:00) [23]
Мужики, ну ведь ясно, что все должно использоваться с умом. Я то про другое, что механизм этот развращает неокрепшие умы. И они пересев с локальных баз на сетевые не перестраиваются, а продолжают мыслить в том же духе.

Digitman (2005-07-27 13:45:00) [24]

> 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:39:00) [25]
Johnmen © (27.07.05 12:17) [32]
Вообще-то, я имел в виду, не транзакции, а ситуации с отложенными изменениями.

Johnmen (2005-07-27 12:17:00) [26]
>pasha_golub © (27.07.05 12:07) [31]
>Я о другом...

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

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

Johnmen (2005-07-27 12:03:00) [28]
>pasha_golub © (27.07.05 11:56) [29]

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

pasha_golub (2005-07-27 11:56:00) [29]
Виталий Панасенко (27.07.05 10:37) [25]

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

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

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

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

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

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

pasha_golub (2005-07-27 11:50:00) [30]
Эта, действительно, транзакции тут не тем местом, как бы.

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

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

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

ksa2002 (2005-07-27 10:39:00) [32]
кэширование хранит данные отедельно
а транзакции уже в базе

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

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

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

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

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

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

Johnmen (2005-07-27 10:11:00) [36]
Механизм кешированных изменений был, есть и будет жить, имея необходимую функциональность в рамках своей идеологии.
Но будучи употреблённым не вовремя, не к месту, без необходимости или без головы, может принести заметный вред, иногда существенный.
С другой стороны - только польза во всех своих проявлениях.

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

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

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

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

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

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

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

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

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

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »