Сохранение данных в файл

SQL не нужен и запросы тоже, только чтение и запись.

А ACID нужно?

Если не нужно, то можно пользоваться std::fstream или FILE*, возможно в связке с (атомарным по определению) rename.

Если нужно, то таки нужна БД: самодельный велосипед погрязнет в детских ошибках и нюансах работы разных ОС и ФС, и никогда из этой трясины не выберется.

CPP
struct Person
Что посоветуете?

boost::serialization

Массивом.

А если уж c++, то std::string же.

boost::serialization

Человеку, который только начал изучать с++, в буст рановато лезть :)

Изучаю CPP

сишный препроцессор? О_о

Ок, записать некоторое количество байтов не проблема. Проблема в том, что name может быть разной длинны, и присчитывании надо распознать где начинается и заканчивается name и начинается age

man 2 open write close

name может быть разной длинны, и присчитывании надо распознать где начинается и заканчивается name и начинается age

Есть два простых и популярных подхода к распознаванию завершения строки при ее считывании:
* читать символ за символом, пока не встретится специальный символ, которым ты условился обозначать конец строки (например, '\n' или '\0')
* перед строкой явно указывать её размер

http://ru.wikipedia.org/wiki/CSV

XML

Проблема в том, что name может быть разной длинны, и присчитывании надо распознать где начинается и заканчивается name и начинается age

Еще вариант - приспособить формат твоего файла к использованию высокоуровневых функций типа scanf или istream::operator >> (string &). http://www.cplusplus.com/reference/string/operator>>/

Изучаю CPP
как можно самому организовать подобие бд

Лучше бы тебе не распыляться. Разберись с C++, потом хватайся за принципы построения БД. Глубина областей почти соразмерна.

По сабжу: бери сериализацию, если данных не много. Иначе sqlite - самое то.

sqlite или XML (если данных мало), все остальное от лукавого

Вот пример, как я сохраняю структуру в бинарный формат: https://github.com/zdo/advp/blob/28c76428cb44d28d5260504b1b5d93056c449be4/src...

boost::serialization

Два чая.

sqlite тоже если данных мало и их не жалко петерять

длинны
блинны
филинны
путинны
оливье

Ну конечно dbm. Позволяет хранить структуры данных переменного размера с помощью индекса и затем извлекать структуру либо используя индекс, либо просто
последовательно просматривая файл.

Ну конечно dbm

+1. А если записи бить на поля, хранить их в базе по отдельности, а саму запись держать как индексные ссылки на поля, то фактически получим «нижнюю часть» SQL машины

sqlite тоже если данных мало и их не жалко петерять

а какие есть альтернативы? чтоб безсерверный вариант с таким же набором настроек журналирования, синхронизации и возможностью бэкапа налету?

berkeleydb

berkeleydb

те же яйца, только в более убогом исполнении

Нет, яйца совершенно другие. Скорость, десятки и сотни миллионов записей, транзакции, полноценная многопоточность и даже многопроцессность, убить базу практически невозможно, полноценная репликация, а не убогий backup api, тонкий тюнинг всего что только можно затюнить, возможность выглядеть снаружи как stl и sqlite ... огромная куча других полезных фичей. Сравнивать sqlite с berkeley это как сравнивать запорожец с мерседесом — совершенно разного уровня продукты.

boost::serialization

его можно советовать только в том случае, если данные не пойдут дальше одного экземпляра программы - оно даже при переезде 32/64 разъезжаются.

убить базу практически невозможно

У нас пацаны отказались от BDB как раз из-за того, что база неоднократно билась.

Скорость, десятки и сотни миллионов записей
транзакции

нет проблем

полноценная многопоточность

ага, в документации сходу пишется про возможные дедлоки, полноценная многопоточность такая полноценная

убить базу практически невозможно

если не отключать журналирование - аналогично, более того журналирование на скорость практически не влияет

тонкий тюнинг всего что только можно затюнить, возможность выглядеть снаружи как stl и sqlite ... огромная куча других полезных фичей

да ладно заливать, возможностей там гораздо меньше чем у sqlite, где есть пользовательские расширения, «виртуалные» таблицы, SQL( только не надо говорить про возможность использовать sqlite поверх bdb ), тонкая настройка авторизации и разграничения прав, временные объекты, full text search, rtree, поддержка icu, profile, explain, trace, логи и пр и пр.

Сравнивать sqlite с berkeley это как сравнивать запорожец с мерседесом

Слишком категорично. BDB может предоставить сопоставимое качество: http://www.sqlite.org/testing.html ?

Transaction subsystem включали? Я использовал и то и то в продакшене. Некорретное выключение машины, сегфолт процесса, некорректное завершение процесса и т.д. и т.п. и sqlite'у в 50% случаев наступал песец. При этом bdb живет под страшной нагрузкой 24/7 ~1000rps в среднем. База переживала всё начиная от смерти машины и заканчивая выключением дц. Ничего никогда не билось.

и sqlite'у в 50% случаев наступал песец

журналирование не выключали?

Transaction subsystem включали?

Деталей не знаю: трахалась с этим соседняя команда. Знаю только, что пацаны вполне грамотные, не быдло и не лохи, и что радости им BDB не принесла.

ага, в документации сходу пишется про возможные дедлоки

И там же рядом в документации написано как с ними бороться. Если кратко, то надо правильно приложение проектировать, да и то для криворуких там предусмотрен костыль — deadlock detector.

если не отключать журналирование - аналогично, более того журналирование на скорость практически не влияет

Ога, даже 10k записей в любом случае поставят sqlite колом.

да ладно заливать, возможностей там гораздо меньше чем у sqlite

Всё перечисленное реализуется на уровне приложения так как ты хочешь. Главное, что в bdb базовый функционал сделан отменно. Например, тот же backup в bdb я могу делать по крону _сторонним_ скриптом, который настроят админы как хотят, а в sqlite трах с backup api внутри приложения, который в случае чего поставит колом систему.

Видимо использовали bdb по рабоче-крестьянски. То есть открыли один файл без окружений, без опций, и начали в него фигачить :) Ибо только в таком случае база может испортиться безвозвратно.

только в таком случае база может испортиться безвозвратно

Им не нужна «возвратность». Им нужна работоспособность 7*24 под бешеной нагрузкой. Охлаждаемая серверная, межделмашевское железо, избыточные рейд-массивы, дизель на случай пропадания света, квалифицированный обслуживающий персонал. Так вот по факту bdb ломалась, несколько раз за несколько месяцев.

У меня оно живет как раз в режиме 24/7. Не ломается. В продакшене под нагрузкой с первого декабря живет. За это время проблемы с сетью и железом были, а с bdb - нет.

У меня есть подозрения, что не включали :)

И там же рядом в документации написано как с ними бороться.

здорово

Ога, даже 10k записей в любом случае поставят sqlite колом.

	sqlite3_exec( db, "CREATE TABLE t1(a INTEGER, b INTEGER, c VARCHAR(100));", 0, 0, 0 );
	sqlite3_exec( db, "CREATE INDEX i1 on T1(a);", 0, 0, 0 );
	sqlite3_exec( db, "CREATE INDEX i2 on T1(b);", 0, 0, 0 );
	
	sqlite3_exec( db, "BEGIN", 0, 0, 0 );
	int i = 0;
	for( i = 0 ; i < 10000 ; ++i )
	{
		char buf[ 512 ];
		sprintf( buf,  "INSERT INTO t1 VALUES(%d,13153,'test');", rand() );
		sqlite3_exec( db, buf, 0, 0, 0 );
	}

	sqlite3_exec( db, "COMMIT", 0, 0, 0 );

0.083сек - прям таки колом

Например, тот же backup в bdb я могу делать по крону _сторонним_ скриптом, который настроят админы как хотят, а в sqlite трах с backup api внутри приложения, который в случае чего поставит колом систему.

http://www.sqlite.org/sqlite.html

просвещайся

Знаю только, что пацаны вполне грамотные, не быдло и не лохи

Судя по лексикону, у вас там всё не так уж хорошо.

0.083сек - прям таки колом

Это пока одна табличка и пока оно влезает в память. Когда перестанет всё ляжет и ничего тебя не спасет.

просвещайся

это?

.backup ?DB? FILE      Backup DB (default "main") to FILE

А разве к sqlite можно безопасно подключаться из стороннего процесса пока оно используется?

Ога, даже 10k записей в любом случае поставят sqlite колом.

Если не коммитить после каждого инсерта, то всё будет пучком. Потому как скорость коммита ограничена скоростью вращения жёсткого диска.

Это пока одна табличка и пока оно влезает в память. Когда перестанет всё ляжет и ничего тебя не спасет.

	sqlite3_exec( db, "CREATE TABLE t1(a INTEGER, b INTEGER, c VARCHAR(100));", 0, 0, 0 );
	
	sqlite3_exec( db, "BEGIN", 0, 0, 0 );
	int i = 0;
	for( i = 0 ; i < 10000000 ; ++i )
	{
		char buf[ 512 ];
		sprintf( buf,  "INSERT INTO t1 VALUES(%d,13153,'test');", rand() );
		sqlite3_exec( db, buf, 0, 0, 0 );
	}

	sqlite3_exec( db, "COMMIT", 0, 0, 0 );

45сек, т.е. на 10млн записей обвала нет, для чего-то большего логично брать тот же postgre, чтоб раскидывать нагрузку и трафик по серверам

А разве к sqlite можно безопасно подключаться из стороннего процесса пока оно используется?

не только можно, но sqlite еще и кэш расшарит

0.083сек - прям таки колом

При разрастании базы до десятков гигабайт, sqlite и правда встаёт на колени. Вот что об этом написано у них на сайте: «Develop a new sort implementation that does much less disk seeking. Use to improve indexing performance on large tables.» http://sqlite.org/cvstrac/wiki?p=ToDo

при испольовании prepare - 8сек вместо 45

Судя по лексикону, у вас там всё не так уж хорошо.

Вась, а по делу есть что сказать?

При разрастании базы до десятков гигабайт

на таких объемах я б точно sqlite не использовал

Про CSV уже сказали. Ваши с Reset'ом меряния *DB - это практически оффтопик.

меряния *DB - это практически оффтопик

Просто у тебя embedded головного мозга.

его можно советовать только в том случае, если данные не пойдут дальше одного экземпляра программы - оно даже при переезде 32/64 разъезжаются.

Прозреваю, что ты делаешь что-то не так. В design goals boost::serialization явно указано: «Data Portability - Streams of bytes created on one platform should be readable on any other.» http://www.boost.org/doc/libs/1_50_0/libs/serialization/doc/index.html

Скорее засада в том, что разные версии буста друг с другом по формату данных могут быть несовместимы. Были соответствующие срачи в списке рассылки, и разработчики четко обозначили свою позицию: они ничего с этой проблемой делать не намерены.

Просто у тебя embedded головного мозга.

Просто я бреду по колено в Ъ-ынтерпрайз кодерах, и у каждого как минимум звание мастера спорта по Си++. ТС спрашивает «как бы мне сохранить структурку с двумя полями?», а через десяток постов начинается: «sqlite или смерть^W XML!!11», «dbm или смерть!!!11», «bdb и смерть вам, неверные!!!11», «ваш sqlite говно, он даже сотню гиг не тянет!!11». При всей любви к Ъ-ЛОР-стайл дискуссии - выдыхайте уже, бобры.

Про CSV уже сказали.

Библиотеку для сериализации/десериализации CSV подскажешь?

ТС спрашивает «как бы мне сохранить структурку с двумя полями?»

а потом к структурке добавится еще одно поле, или изменится тип данных - и твоя простая и удобная картина мира вдруг потускнеет, а потом окажется, что записей таки будет много и/или их потеря будет критичной - и станет совсем мрачно

а через десяток постов начинается

дык не читай