Вообщем часто энтузиазисты пытаются создать что-то свое с нуля - раздел проджектс у нас просто кишит подобными проетами. БОльшая часть из них так и глохнет на стадии а давайте .... Меня посетила мысль что неплохо было бы сделать энциклопедию таких велосипедов которая бы содержала описание базового функционала и технологий в нем использующихся ... Вся эта хрень к тому, что я надумал прикрутить сохранение конфигурации к своему командеру и пришел к выводу, что совокупность параметров конфигурации нужно хранить как примитивную БД ... нужно описание БД-велосипеда
я надумал прикрутить сохранение конфигурации к своему командеру и пришел к выводу, что совокупность параметров конфигурации нужно хранить как примитивную БД ... нужно описание БД-велосипеда можно сказать что да, нужны доки чтобы сделать свой велосипед
Не нужно. К примеру Mozilla Firefox юзает sqlite в качестве локальной базы. Впрочем как и масса других прог. Просто и доступно. У меня даже валяется исходник на ASM для работы с ней.
Зачем приложению хранить свои две с половиной настройки в бд? Никто конечно не запретит, просто смысл. Прочитать в мапу, серилизовать. Чего ещё надо?
БД не нужна. Достаточно взять XML. Для особых эстетов можно потом на шарпе визуальный конфигуратор проги накатать за пару часов.
http://www.garret.ru/databases.html Хотя, если не нужны транзакции и проч., а только быстрый индексный доступ, то лучше всего взять какое-нибудь дерево (B+Tree, например). SQLite, сколько помню, хранит все в виде текста, что может потребовать двойной конверсии при чтении/записи. Под Linux просто немеряно подобных вещей (смотрите в сторону QDBM - Quick Database Manager и клонов). Довольно давно, для собственных нужд, я использовал Jan Jannink B++Tree (http://infolab.stanford.edu/~jan/). Сейчас, если поискать, можно найти и другие готовые реализации. В отличие от BTree, в B+Tree доступ к ключам возможен как к сортированному списку, что может быть удобно/важно для некоторых приложений.
Реестр - база данных ini-файл - очень примитивная, конечно, но база данных а за использование sql, пусть даже и lite, для хранения настроек (!!! сколько их там? 5, 10, 100 записей? как часто их запрашивать? по 40 раз в секунду или 1 раз в начале работы и по 1 разу при изменении?) надо по рукам бить, линейкой. Или крышкой ноута пальцы прищемлять )))
Есть куча готовых библиотек, разной степени глючности, но, IMHO, порочна сама идея. Если нужно компактно + быстрый доступ - храним бинарно, организовывая в хэш, дерево или иную структуру с гарантированным временем отклика. Если важно readability - храним в текстовых конфигах a la *nix, пишем свой DSL для парсинга (http://en.wikipedia.org/wiki/Domain-specific_language). XML - лучший способ сделать все через ж... - медленно, громоздко, нечитаемо.
А чем тогда использование SQLite отличается от использования библеотеки парсинга XML ? И то и то ресурсоемко и по сути "из пушки по воробьям" для хранения 10-20 параметров явно избыточно ....
Лично мне нравится подход mc. Конфиг - каталог, в котором лежат несколько конфигурационных файлов - history, bindings, hotlist и т.д. Формат этих конфигов очень прост и заточен под конкретные нужды. Удобно размешать такой конфиг как в каталоге с программой так и в каталоге юзера. Не стоит искать сложностей. DLS не нужен.
http://ru.wikipedia.org/wiki/MetaKit http://equi4.com/metakit/ небольшой (меньше склайт), быстрый и достаточно мощный (например, поддерживает рекурсию полей таблицы, множественные операции над отображениями таблиц, объединение выборок из разных таблиц в одно отображение итд. и все это операторами. например: Vr = T1 & T2 бд движок предназначенный для встраивания. написан на ++. имеет небольшой набор интерфейсных примитивов. определено довольно много операций над базами и отображениями таблиц.
