Мастера 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)
Считаете ли вы порочным механизм кешированных апдейтов и почему?

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

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

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

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

isasa (2005-07-30 11:38:00) [2]
>Проблемы одновременного редактирования одного и того же рекорда нет

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

AxelBlack (2005-07-29 19:32:00) [3]
>To be or not to be?
однозначно to be
Проблемы одновременного редактирования одного и того же рекорда нет при грамотной проектировке и разработке приложений и при грамотном reconcile (без блокировки на сервере)

ЮЮ (2005-07-29 03:21:00) [4]
>pasha_golub © (28.07.05 19:27) [53]

а TClient DataSetбудто не потомок TDataset :)

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

Rule (2005-07-28 15:43:00) [6]
добавляю от себя, игнорируя все вышесказанное ...

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

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

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

...

Polevi (2005-07-28 14:12:00) [7]
>DiamondShark © (28.07.05 13:57) [50]
ну вот и славно, а то бесится.. не надо дорогой

DiamondShark (2005-07-28 13:57:00) [8]

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

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

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

DiamondShark (2005-07-28 13:28:00) [10]
Ой, вот что больше всего бесит, так это позиция: "Теоретики -- это, конечно, всё хорошо, но у нас тут особая практика".

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

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

Андрей Жук (2005-07-28 12:58:00) [12]
Проблема такая существует, и проектировщик должен ее учитывать. Выбирая или оптимистическую, или пессимистическую блокировку.

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

Андрей Жук (2005-07-28 11:43:00) [14]
Одна из основных проблем при разработке многопользовательских приложений баз. данных — обеспечить одновременный доступ максимальному количеству пользователей при согласованном чтении и изменении данных каждым из них. Механизмы блокирова- ния и управления одновременным доступом, позволяющие решить эту проблему, являют- ся ключевыми в любой базе данных, и в СУБД Oracle они весьма эффективны.

Ega23 (2005-07-28 11:37:00) [15]
Том Кайт (а это цитата из него) думаю, больший спец по БД...

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

Андрей Жук (2005-07-28 11:22:00) [16]
Том Кайт (а это цитата из него) думаю, больший спец по БД...

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

DiamondShark (2005-07-27 21:19:00) [18]

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

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

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

Андрей Жук (2005-07-27 15:03:00) [20]
Потерянные изменения Потерянное изменение — классическая проблема баз данных. Если коротко, поте- рянное изменение возникает, когда происходят следующие события (в указанном по 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) такой защиты не обеспечивают. Как средства разработки, обеспечивающие защиту (за кадром), так и разработчики, использую щие другие средства (явно), должны применять один из двух описанных ниже методов блокирования.

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

Наверх

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