Альтернативы SQLite для [закрытого] C++

I would argue that the added dependency on a wrapper library is not worth the cost of having to deal with the costs of that extra dependency. You don't want to be stuck debugging these wrapper libs when the documentation for them may be scant. SQLLite is bound to be more stable and have better documentation and therefore a more reliable dependency.

I would either deal with sqllite or wrap it yourself in some intelligent way based on your end application.

Berkeley DB aka SleepyCat. If you search the archives there is an article by Mike Olsen that talks about the major disadvantages of SQL in any project. There is another followup article within the last year that suggests that SQL is on it's way out because the ORM layers are getting so much better.

Согласен, странно сказать, что SQLite несовместим ни с C ++, ни с индексированием имен столбцов. Существует множество оболочек C ++ SQLite, которые поощряют доступ к столбцам по имени. SQLite ++ является лишь одним из многих.

Могу ли я предложить вам список API-оболочек , перечисленных на сайте Sqlite? Там есть много для многих языков, включая C ++. Sqlite Plus выглядит особенно хорошо. POCO, о котором «обычно бесполезно» упоминается, тоже выглядит хорошо.

Instead of a sql derivative, you might think about using an inverted index IR library like Lucene (or one of the many clones out there). I know Lucene is Java, but you could write a managed C++ library to interop with Lecene.Net.

As far as speed, I'm very happy with the performance of Lucene for its reads. Its not as optimized for its writes, but its still pretty good, as long as your not trying to build an index of millions of "documents".

If you're not working on Windows, you might look into Tokyo Cabinet. It looks to be quite good. I'm waiting for the Win32 port, so I can't say much about it other than the performance looks to be impressive.

http://anyall.org/blog/2009/04/performance-comparison-keyvalue-stores-for-language-model-counts/

This is not an SQL derivative. It's a straight b-tree/hash based store. This is very welcome, in my opinion. The only competitive library that I'm aware of is Berkeley DB, which has less than desirable licensing.

Звучит так, как будто база данных является единственной реальной возможностью для вас. Однако если вы выбрали SQLite, MySql или Postgres, в индексной точке столбца значения не имеют.

Возможно, вам действительно нужна лучшая абстракция базы данных. Возможно, вы захотите попробовать Poco, у него есть отличный вариант: http://pocoproject.org/

Если синтаксис SQL для вас не важен, я рекомендую MetaKit - Это немного другой подход, но он достаточно мощный, и мне лично известно о нескольких коммерческих проектах. которые используют его успешно, даже на встроенных системах.

Это Учебное пособие l очень полезно для начала.

Если вы попросите меня остаться с SQLite и «сделай это сам» - упаковка довольно проста. Я сам делал различные оболочки над SQLite. Зачем? Потому что его API намного удобнее, чем все остальное, связанное с базами данных, и вам не нужно тратить много усилий. С библиотекой оболочки вы только добавите больше неизвестных, и, что наиболее важно, большинство оболочек не предназначены специально для обслуживания встроенных баз данных. Я всегда повторяю, что правильный подход со встроенной базой данных сильно отличается от оптимального подхода для сервера базы данных ...