Здравствуйте Grog13M, Вы писали:
GM>Здравствуйте Sinclair, Вы писали:
GM>>>Как по науке решается вопрос о синхронизации? Может какие-то примеры? S>>Главное ключевое слово — ACID (Atomicity, Consisteny, Isolation, Durability). Второе ключевое слово — transaction. GM>>>И какую БД лучше использовать для этих нужд? S>>Ту, которая поддерживает транзакции. Почти все современные СУБД это делают. Никаких усилий (почти) по синхронизации приложений не потребуется.
GM>Ага, я понял, принцип транзакции "либо все, либо ничего" GM>После того как юзер сделал COMMIT, то любые другие юзеры при SELECT'ах увидят измененное состояние, если СЕЛЕКТ был после КОММИТА и предыдущее состояние если до?
Ну, то что на самом деле увидят усеры сильно зависит от так называемого "уровня изоляции" транзакций, в которых они находятся и от используемой модели поддержки кислотности. Например, при дефолтной изоляции (Read Committed) в MS SQL Server усеры, пытающиеся сделать селект по данным, которые сейчас кто-то пишет, будут вынуждены ждать коммита. А вот в interbase, например. они действительно увидят предыдущее состояние.
GM>Т.е. в самом приложении ничего по синхронизации данных делать не надо? Или?
Да. Ничего делать не надо. Прежде всего потому, что дело это дюже сложное, и в стандартные БД встроено более чем достаточно возможностей для поддержки всех типичных сценариев синхронизации.
GM>Порекомендуйте, пожалуйста, какую-нибудь простенькую БД, с возможностью транзакций. GM>Стоять это все будет по Win2000 или WinXP.
Гм. Увы, я не спец в этих вопросах. По идее, MS Access должен это все уже уметь — лень читать доку.
А так, под виндою, я считаю, лучче MS SQL нету. Тем более теперь он даже в CE варианте есть, то ись совсем нетребовательный зверек.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.