Cached updates. To be or not to be?

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

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

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

← →
Polevi © (2005-07-28 08:53) [41]

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

← →
Андрей Жук © (2005-07-28 11:22) [42]

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

← →
Ega23 © (2005-07-28 11:37) [43]

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

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

← →
Андрей Жук © (2005-07-28 11:43) [44]

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

← →
Polevi © (2005-07-28 12:43) [45]

>Андрей Жук © (28.07.05 11:43) [44]
блокировки и транзакции тут абсолютно не причем

← →
Андрей Жук © (2005-07-28 12:58) [46]

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

← →
Polevi © (2005-07-28 13:12) [47]

>Андрей Жук © (28.07.05 12:58) [46]
да ради бога, учитывай
теоретик ты наш
пользователям Кайта своего почитай

← →
DiamondShark © (2005-07-28 13:28) [48]

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

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

← →
Polevi © (2005-07-28 13:34) [49]

>DiamondShark © (28.07.05 13:28) [48]
ты не волнуйся, все будет хорошо

← →
DiamondShark © (2005-07-28 13:57) [50]

> Polevi © (28.07.05 13:34) [49]

А у меня и так всё хорошо.
Плохо у прапорщиков.

← →
Polevi © (2005-07-28 14:12) [51]

>DiamondShark © (28.07.05 13:57) [50]
ну вот и славно, а то бесится.. не надо дорогой

← →
Rule © (2005-07-28 15:43) [52]

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

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

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

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

...

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? Найти похожие ветки