LINUX.ORG.RU

Нужен совет по хранению данных


0

0

Уважаемые форумчане! Подскажите пожалуйста, как лучше хранить следующие данные:

Набор записей, среди элементов (полей) которых нет уникальных (т.е. уникальный ключ можно ввести, но он не будет нести смысловой нагрузки). Есть элементы, по которым требуется сортировка, выборка и поиск (например, время последнего доступа к записи). Множественный доступ к данным, блокировки, транзакции, триггеры и прочая не требуются. Обновления некоторых элементов происходят часто (то же время последнего доступа). Записей много (тысячи, десятки тысяч). Размер элементов - умеренный (максимум - строка текста не больше ~сотни символов).

Делать такую упрощенную БД самому несколько лень. DBM - просто ассоциативный массив и здесь никак ситуацию не облегчит (или я не прав?). Какой-нибудь MySQL - вероятно, слишком наворочен и неоправдан для такой задачи.

Да, доступ к данным - из моей программы, желателен интерфейс на C/C++.

anonymous
Ответ на: комментарий от Begemoth

db4 - имеется в виду четвертая версия Berkeley DB? Так это и есть разновидность DBM, я про нее знаю (там и к Java, Tcl, Perl интерфейсы есть). И БД эта представляет собой ассоциативный массив типа ключ-значение. Правда, порывшись в документации у них на сайте я нашел упоминание о вторичных индексах, но реализуются они через создание второй БД (у которой вторичный индекс будет ключом, а значение - ключом от главной БД). Там же приведены примеры с альтернативой на SQL - честно говоря DB-шные примеры в таком соседстве выглядят страшненько.

Так что, думаете стоит использовать Berkeley DB? У меня предполагается по меньшей мере 3 вторичных индекса - соответственно 4 БД вместо одной... Кроме того, как там с сортировкой? Я просто никогда не работал с DBM, а бегло пробежавшись по документации на www.sleepycat.com увидел лишь шуструю реализацию доступа к ассоциативным массивам на диске. Может я здорово ошибаюсь? Если нет, то DB не сильно облегчит мне задачу.

anonymous
()

> Какой-нибудь MySQL - вероятно, слишком наворочен и неоправдан для такой задачи.

Какой-нибудь Oracle или DB2 действительно слишком наворочан.

MySQL для таких задач - то, что доктор прописал.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

>>MySQL для таких задач - то, что доктор прописал.

Блин, я-то думал, что он только как отдельный процесс-сервер работает, а он вроде может и в клиент встраиваться. Тогда вроде действительно подходит, спасибо.

anonymous
()
Ответ на: комментарий от anonymous

1. MySQL работает как отельный процесс сервер - в прогу встраивается клиентская библиотека.

2. насчет использования Berkley DB - не знаю

Begemoth ★★★★★
()
Ответ на: комментарий от anonymous

Если нужно что-то встроить в клиента функционал SQL, см. в сторону embedded interbase / embedded firebird

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

> MySQL для таких задач - то, что доктор прописал.

или sqlite. Проще тем, что не надо заморачиваться поднятием и конфигурацией сервера. Все работает сразу.

AngryElf ★★★★★
()

Подходит всё. В конце концов, плюнь и храни в плоском файле... Который можно прочесть в память -- если там не десятки миллионов записей...

С уважением -- Смоляное Чучелко

anonymous
()
Ответ на: комментарий от anonymous

О! SQLite - это весьма близко к тому, о чем я грезил. Думаю на ней и остановлюсь.

Кстати, MySQL таки может встраиваться в клиент. Там есть специальная библиотека - libmysqld.a. Только чтобы ее получить надо собирать с configure-ключом --with-embedded, что редкий построитель пакетов делает.

Спасибо за советы!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.