Re[12]: Правильная организация интерфейса базы данных
От: Softwarer http://softwarer.ru
Дата: 15.07.05 08:27
Оценка:
Здравствуйте, Arsu, Вы писали:

A>Оптимистическая — это когда ресурсы блокируются в момент сохранения изменений — это, конечно, повышает параллельность и масштабируемость


Оптимистическая блокировка в общем случае не то чтобы заметно повышает параллельность и масштабируемость. Просто другой подход легко может убить блокировочник

Концептуально же параллельность повышается только для варианта "один человек редактирует левую половину записи, другой — правую половину записи", что, назовем так, довольно сомнительный подход.

A>Первый вывод. Если ты используешь TDBEdit'ы и т.п. в том же духе — то есть компоненты прямого доступа в БД, то ты при наложении изменений — теряешь данные (или первого юзера, или второго).


Вывод неправильный (c) полковник Петренко.

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

A>Второй вывод. Если используешь оптимистичекую блокировку, то конфликты надо регулировать. Ручками чаще всего.


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

A>Куда определить транзакции — это, конечно, вопрос. Однако хочу заметить, что ты будешь создавать по транзакции на окно, то это не решит проблему потери данных. А если это не решает проблем, то зачем это делать?


Брр. "Вывод неверный".

Основное и даже единственное, что решают несколько транзакций — возможность независимого редактирования в немодальном интерфейсе. Например, если началось редактирование документа, потом была вставлена запись в справочник, потом пользователь отказался от сохранения документа — запись справочника сохранится, а не потеряется при rollback-е документа. Тем более это актуально, когда возможно параллельно редактировать несколько документов.

A>Проблема, мне кажется, именно в этом — как обрабатывать конфликты при сохранении изменений.


Гораздо удобнее их не допускать.

A>Мне лично кажется логичным, если эти конфликты будет решать нечто в единственном экземпляре — соответственно, и транзакция у этого "нечто" может быть всего одна — так и так он всех в очередь построит.


Хм....... Ничего не понял.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.