Телефонный справочник или оптимизация скорости работы с данными

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

То есть, судя по условиям задачи при запуске программы необходимо все данные подгружать в оперативную память. И тут возникает вопрос, в каком виде хранить данные внутри программы? При этом необходимо учитывать, что данные должны редактироваться, а значит нужен индекс, так как в заданной структуре отсутствуют уникальные поля.

Для удовлетворительных результатов по скорости загрузки из файла и в файл я выбрал двоичную сериализацию (практическим путем выявил, что данный вид хранения является самым выгодным по скорости и размеру файла данных).

Тестирую на 5000000 элементах в каждом из которых по 7 полей типа string. Пока ничего более дельного, кроме List<string[]>(либо object[]) в голову не пришло. Перепробовал множество способов но все либо очень долгое, либо требует очень много оперативной памяти.

Хотелось бы узнать Ваше мнение по этому поводу.
Заранее спасибо.

0

Номер телефона, по определению, уникален. Если все записи фиксированного размера, то перезапись удаленных номеров элементарна. Идеальный вариант хранения в этом случае: .DBF с индексом или аналогичная структура. Если размер записей произволен: .DBF + Memo с индексом (или аналогичная структура).

Индекс - либо "key-value DB" (для "больших" данных), либо любой map (словарь) в памяти.

1

Может, все-таки необязательно все данные сразу загружать в память?
Если объемы такие большие, по-моему проще будет взять БД (SQLite, например) и с ней работать.
Нужны данные - отправили запрос, данные получили

1

Да, Вы безусловно правы, самым разумным было бы использовать SQL, но к сожалению необходим именно файл( Причем надо сделать так, чтобы при загрузке/сохранении/обработке данных пользователь не умер от старости при теж же 5млн элементов)).
Удалось достичь результата: 5млн записей загрузка/сохранение занимает ~5сек. Манипулирование данными ~300млс.

Я так полагаю, что данное время загрузки/сохранения обусловлено физическими характеристиками передачи данных HDD.

0

Сообщение от iDarius необходим именно файл

iDarius, вы, наверное, не поняли... Не SQL, а именно SQLite. Для него не надо ничего развертывать на машине пользователя. Только приложение + файл с базой данных. Подумайте над
этим, это лучший вариант, ятд.

2

Сообщение от insite2012 приложение + файл с базой данных

+ DLL-ка (~400 Kb от SQLite). Поддерживаю - лучший вариант.

2

Сообщение от gazlan + DLL-ка (~400 Kb от SQLite).

И ее так же можно в исполняемый файл (если есть такое желание) заинжектить)))

1

Это я все прекрасно понимаю, но был поставлен запрет на дополнительные компоненты, не входящие в поставку MS .NET Framework 3.5. Без данного ограничения у меня не было бы причины создавать эту тему, я бы сразу прикрутил SQLCe либо SQLite, но мои представления о развертывании локальной БД с помощью стандартных компонентов .NET Framework достаточно скудны. Если бы вы могли подсказать в какую сторону копать, я был бы очень благодарен))

0

Сообщение от iDarius представления о развертывании локальной БД с помощью стандартных компонентов .NET Framework достаточно скудны

То есть, dll от SQLite использовать нельзя, я верно понял? А если взять самое простое - БД от Access? Там никакие либы вообще не нужны. Все есть в .NET. Как вариант?

1

Сообщение от insite2012 То есть, dll от SQLite использовать нельзя, я верно понял?

К сожалению это так.

Сообщение от insite2012 А если взять самое простое - БД от Access

На эту тему я пока не разбирался, но первое что пришло в голову это при необходимости работы с *.doc/*.docx файлами поднимался процесс "MSWORD", и на компьютерах, где отсутствовал установленный MSOffice программа крашилась. Основываясь на этом, не затребует ли работа с MS Access предустановленного Office'a?(К сожалению возможности проверить нет)

0

Сообщение от iDarius не затребует ли работа с MS Access предустановленного Office'a?

Нет, ничего она не затребует. Все работает стандартными средствами .NET. Только исполняемый файл и база (ну и .NET Framework, естественно ).

1

insite2012, это очень хорошо) Я более подробно изучу данную возможность. Спасибо за помощь)

0