Хранение данных .NET - что-то среднее между встроенными коллекциями и внешней базой данных SQL?

Question

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

Я часто нахожу себя пишущим небольшую программу, которая все делает более или менее одно и то же:

1. Чтение данных из одногоили более файлов
2. Сохраните эти данные в памяти, в каком-то контейнере
3. Пересмотрите данные, выведите результаты анализа в текстовый файл и выйдите из системы

Я часто нахожуЯ создаю чудовищно выглядящие контейнеры для хранения указанных данных.Например:

Dictionary<DateTime, SortedDictionary<ItemType, List<int>>> allItemTypesAndPropertiesByDate =
            new Dictionary<DateTime, SortedDictionary<ItemType, List<int>>>();

Это работает в том смысле, что структура данных более или менее точно описывает мое намерение - я хочу иметь возможность доступа к типам элементов и свойствам по дате.Тем не менее, я чувствую, что контейнер хранения слишком тесно связан с форматом выходных данных (если завтра я решу, что хотел бы найти все даты, в которые были видны элементы с определенными свойствами, эта структура данных становится пассивом).Как правило, внесение изменений на входе и выходе вниз по линии занимает много времени и подвержено ошибкам.Кроме того, я должен продолжать смотреть на эти уродливые объявления - и код для их перебора тоже не из приятных.

На другом конце спектра сложности я могу создать базу данных SQL со схемой, которая описываетвведите в более гибкий формат, а затем выполните запросы (используя SQL или LINQ to SQL) к базе данных.Это, конечно, работает, но кажется слишком большим молотком - я пишу много подобных программ, и не хочу создавать базу данных для каждой, управлять зависимостью SQL (даже если это SQL Express на локальной машине) и т. Д.Мне не нужно на самом деле сохранять данные - просто чтобы прочитать их, сохранить в памяти, сделать несколько запросов и выйти.Даже использование экземпляра SQLite в памяти кажется излишним.Я не слишком обеспокоен производительностью во время выполнения - это обычно просто небольшие эксперименты на локальной машине - но это просто кажется неправильным.

В идеале, я хотел бы иметь низкие накладные расходы,в памяти строк хранится со слабо определенной схемой, которая легко запрашивается LINQ и требует всего лишь нескольких строк кода для настройки и использования.В стек Microsoft .NET 4 входит что-то подобное?Если бы вы оказались в подобном затруднительном положении, что бы вы сделали?

Ваши мысли ценятся - спасибо!

Алекс

Answer 1

Если вам проще работать со структурой базы данных, одним из вариантов может быть создание набора данных с таблицами данных, представляющими вашу схему, которые затем можно запросить с помощью Linq 2 DataSets

Answer 2

Сравнивая базы данных и ООП, определение таблицы соответствует определению класса, запись - это объект, а данные таблицы - это любая коллекция объектов.

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

Этот список можно затем запросить с помощью Linq.

Answer 3

Почему бы просто не использовать linq?

Вы можете прочитать данные в плоские списки, а затем объединить некоторые операторы linq, чтобы получить желаемую структуру.

Извинения, если я что-то упустил,но я не думаю, что вам нужен промежуточный.

Answer 4

Или вы можете попробовать использовать объектные базы данных, такие как db4o ; они хранят реальные объекты, с которыми вы будете работать, помогая программировать более объектно-ориентированным образом, и с ними довольно легко работать. Кроме того, это не сервер базы данных в традиционном смысле этого слова - он использует плоские файлы в качестве контейнеров и читает / записывает непосредственно из / в них.