Вы снова задаете неправильный вопрос:)
Лучший вопрос: «Как мне создать приложение, которое позволит мне изменить реализацию хранилища данных?»
Если вы примените шаблон репозитория и правильно подключите его к интерфейсу, вы можете создать сменные слои постоянства. Таким образом, вы можете начать с одной реализации и изменить ее по мере необходимости, не прибегая к реинжинирингу бизнес-уровня или уровня приложений.
Если у вас есть интерфейс репозитория, вы можете попробовать реализации в самых разных подходах:
Плоский файл - Вы можете сохранить данные в формате XML, и при условии, что это не очень много данных, вы можете сохранить все содержимое в памяти (просто прочитайте файл при запуске, запишите файл в неисправность). С XML в памяти вы можете получить очень высокую пропускную способность, не заботясь об индексах базы данных и т. Д.
Распределенная БД - SQLite или SQL Compact отлично работают; они предлагают множество преимуществ БД и не требуют установки
Локальная БД - SQL Express является хорошим промежуточным звеном между облегченной и полнофункциональной БД. Доступ при правильном использовании может быть достаточным. Основное преимущество заключается в том, что он включен в MS Office (хотя и не установлен по умолчанию), а некоторым ИТ-группам удобнее устанавливать Access на компьютерах, чем SQL Express.
Полная БД - MySql, SQL Server, PostGreSQL и др.
Учитывая ваши конкретные требования, я бы посоветовал вам создать плоский файл на основе XML - с единственным условием, если вы согласны с использованием памяти приложением, которое напрямую зависит от размера файла (поскольку ваши данные текст, даже с весом XML, потребует много записей, чтобы стать очень большим).
Вот плюсы / минусы - перечислены ваши требования:
Против
- Нет ограничений на количество введенных данных.
- использование XML в памяти будет означать, что ваше приложение не будет масштабироваться. Он может легко обрабатывать 10 МБ файла данных, 100 МБ не должно быть проблемой (если у вашей системы недостаточно ОЗУ), кроме того, вы должны серьезно задуматься: «Могу ли я позволить себе столько памяти?».
Плюсы
- Один пользователь на приложение. Нет одновременной активности или нескольких пользователей.
- XML можно читать в память и удерживать процессом (на самом деле AppDomain). Он идеально подходит для однопользовательских сценариев, где параллелизм является очень узкой задачей.
- Разрешить экспорт пользовательских записей / данных во внешний файл, который может быть легко распространен между приложениями / пользователями.
- XML идеально подходит для экспорта, а также его легко импортировать в Excel, базы данных и т. Д. *
- Позволяет в пользовательских запросах отображать клиентов на основе различных комбинаций информации о клиенте / информации о месте работы.
- Linq-to-XML - ваш друг: D
- Данные никогда не будут просматриваться или обрабатываться за пределами приложения.
- .... тогда хранение его в памяти не вызывает проблем
- Программа будет работать почти всегда, свернутая на панель задач.
- , поэтому загрузка XML при запуске и запись при завершении работы будут приемлемыми (если файл очень большой, это может занять некоторое время)
- Время запуска не очень важно, однако я бы хотел, чтобы запросы выполнялись значительно быстрее
- Чтение XML будет относительно медленным при запуске; но когда он будет загружен в память, его будет трудно победить. Любая конкретная БД потребует, чтобы механизм БД был запущен, чтобы выполнялись вызовы взаимодействия / межпроцессного / межсетевого взаимодействия, чтобы результаты загружались с диска (если не кэшированы механизмом) и т. Д. *