Использование базы данных MS Access в качестве формата файла для настольных приложений, требующих функциональности открытого/безопасного типа

Question

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

Я написал инструмент, который делает большие вещи типа калькуляции. В настоящее время он состоит из библиотеки классов и инструмента командной строки (отдельные .NET-проекты). Мы используем формат базы данных Access в качестве типа файла, так как он может хранить все разные таблицы в одном файле. Несколько других вопросов о приложении: - Пользователей мало. Нет проблем с масштабируемостью. - Нет проблем с обновлениями. - Рабочий стол желательно. Не в Интернете. - Использование VB и .NET 3.5 SP1

Теперь мне нужно разработать интерфейс GUI, который позволит выполнять типичные операции File/Open и File/Save.

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

Имеет ли смысл использовать временный файл для чего-то вроде прокси? В случае, когда пользователь «открывает» файл, скопируйте исходный файл доступа в локальный файл temp и затем используйте его для сеанса редактирования? Затем, если пользователь «сохраняет», скопируйте локальный файл temp обратно в исходный путь?

Является ли этот вопрос понятным? Является ли дизайн ужасным ??? Любые комментарии или предложения?

Обновление: [с тегом ms-access too] Кроме того, я опустил тот факт, что пользователи также ожидали бы обычной функции File/Save As. Я думаю, что дизайн, который я поставил под вопрос в этом посте, - это традиционно называемый шаблон прокси-дизайна. Кто-нибудь пробовал это (успешно!) С файлами базы данных Access раньше? Предупреждения или советы?

Answer 1

Ну, этот подход будет работать, но это не самый лучший дизайн в мире. То, о чем вы говорите, это транзакции, в основном. Транзакция представляет собой набор операций для базы данных, которые являются атомарными, либо они ВСЕ идут, либо ни одна из них не выполняет.

Обычно вы скопируете транзакцию с BEGIN и COMMIT. Таким образом, транзакция не включает всю базу данных, а только те части, которые вы сейчас работаете.

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

Но если пользователь рассчитывает открыть БД, внести здесь несколько изменений, зафиксировать их, затем внести несколько изменений, а затем отменить их, это не сработает.

Answer 2

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

Как упоминалось в @drventure, обычно вы должны использовать транзакции, чтобы контролировать, будут ли изменения сохранены или нет, но в вашем приложении вам нужно будет начать транзакцию «gobal» после открытия базы данных доступа и совершения или отказа от этой транзакции в зависимости от что делает пользователь. Однако я понятия не имею, как Access выполняет обработку транзакции с несколькими изменениями в нескольких таблицах, которые «открыты» в течение длительного времени ...

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