Alternativas de SQLite para C ++ [cerrado]

Question

Estoy desarrollando una aplicación que necesita almacenar datos con muchas escrituras y lecturas que requieren una búsqueda rápida de datos (la necesidad de índices de algún tipo), y también ser capaz de serializar y guardar los datos.

Actualmente estoy pensando en usar SQLite, que hace el trabajo, pero estoy abierto a alternativas. La sintaxis de SQLite realmente no encaja elegantemente en el código C ++ (por ejemplo, me veo obligado a acceder a los resultados por números de índice de columna en lugar de nombres de columna, etc.).

Answer 1

Quédese con SQLite pero encuentre una buena biblioteca de C ++ para esto.

Esta pregunta de StackOverflow debería ayudarlo. ..

Answer 2

Yo diría que la dependencia adicional en una biblioteca de contenedor no vale el costo de tener que lidiar con los costos de esa dependencia adicional. No querrá estar atascado depurando estas librerías de envoltura cuando la documentación para ellas puede ser escasa. SQLLite seguramente será más estable y tendrá una mejor documentación y, por lo tanto, una dependencia más confiable.

Yo trataría con sqllite o lo envolvería usted mismo de una manera inteligente basada en su aplicación final.

Answer 3

Parece que una base de datos es la única opción real para usted. Sin embargo, si elige SQLite o MySql o Postgres, realmente no importa en el punto de índice de la columna.

Quizás lo que realmente quieres es una mejor abstracción de la base de datos. Es posible que desee probar Poco, tiene uno excelente: http://pocoproject.org/

Answer 4

Berkeley DB, también conocido como SleepyCat. Si busca en los archivos, hay un artículo de Mike Olsen que habla sobre las principales desventajas de SQL en cualquier proyecto. Hay otro artículo de seguimiento en el último año que sugiere que SQL está en camino porque las capas de ORM están mejorando mucho.

Answer 5

Si me preguntas quédate con SQLite y "hazlo tú mismo" - la envoltura es bastante simple. Hice varias envolturas sobre SQLite yo mismo. ¿Por qué? Debido a que su API es mucho más amigable que cualquier otra cosa relacionada con la base de datos y no necesita gastar mucho esfuerzo. Con una biblioteca de contenedor solo agregará más incógnitas y, lo que es más importante, la mayoría de los contenedores no están especialmente dedicados a servir bases de datos incrustadas. Siempre estoy repitiendo que con la base de datos integrada, la forma correcta es muy diferente del enfoque óptimo para un servidor de base de datos ...

Answer 6

Si la sintaxis SQL no es importante para usted, le recomiendo MetaKit : es un poco diferente enfoque pero es bastante poderoso y personalmente conozco más de unos pocos proyectos comerciales que lo usan con éxito, incluso en sistemas integrados.

Esta Tutoria l es bastante útil para comenzar.

Answer 7

¿Puedo sugerirle que tome una lista de las API de envoltura enumeradas en el sitio de Sqlite? Hay mucho para muchos lenguajes, incluido C ++. Sqlite Plus se ve particularmente bien. POCO, que 'usualmente inútil' mencionó, también se ve bien.

Answer 8

Estoy de acuerdo, es falso decir que SQLite es incompatible con la indexación de nombres de columnas o C ++ Hay muchos envoltorios SQLite de C ++ que fomentan el acceso a las columnas por nombre. SQLite ++ es solo uno de muchos.

Answer 9

En lugar de una derivada sql, puede pensar en usar una biblioteca IR de índice invertido como Lucene (o uno de los muchos clones disponibles). Sé que Lucene es Java, pero podría escribir una biblioteca C ++ administrada para interoperar con Lecene.Net.

En cuanto a la velocidad, estoy muy contento con el rendimiento de Lucene para sus lecturas. No está tan optimizado para sus escrituras, pero sigue siendo bastante bueno, siempre y cuando no intentes crear un índice de millones de "documentos".

Answer 10

Si no está trabajando en Windows, puede buscar en el Gabinete de Tokio. Parece estar bastante bien. Estoy esperando el puerto Win32, así que no puedo decir mucho más que el rendimiento parece ser impresionante.

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

Esto no es una derivada de SQL. Es una tienda basada directamente en b-tree / hash. Esto es muy bienvenido, en mi opinión. La única biblioteca competitiva que conozco es Berkeley DB, que tiene licencias menos que deseables.