Inteligente o no: Persista datos serializados (dotnet-protobuf, protobuf-net, json) en una base de datos relacional en CF

Question

Comencé a leer algunas de las publicaciones relacionadas con las memorias intermedias de protocolo. El método de serialización parece muy apropiado para la transferencia de datos hacia y desde servidores web. ¿Alguien ha considerado usar un método como este para guardar y recuperar datos en el dispositivo móvil en sí mismo? (es decir, un reemplazo para una capa de base de datos/orm tradicional) Actualmente usamos un orm basado en reflexión personalizado. Queremos alejarnos del uso de la reflexión en los dispositivos móviles. Y, dado que tenemos que enviar/recibir datos serializados de todos modos, esto parece una buena opción.

• ¿Dónde se guardarán los datos?
• ¿Cómo se consultarán los datos?

¿Tendría sentido almacenar los datos en una base de datos tradicional (SqlCE o SqlLite) con unas pocas columnas "buscables" y luego una columna para los datos serializados?

¿Pensamientos? ¿Estoy en una extremidad aquí?

Actualización: esta misma "teoría" podría funcionar para otros tipos de datos serializados también ... JSON por ejemplo. No he podido encontrar una opción NoSQL para almacenar y consultar datos serializados en Compact Framework. También me interesaría esa opción si alguien sabe de una.

Opina sobre bases de datos de objetos He intentado con db4o y Prest. db4o fue absolutamente maravilloso para trabajar. Lo usé en "la vida real" y el rendimiento, la usabilidad y la capacidad de mantenimiento fueron excelentes. Sus tarifas de licencia para nuestra situación fueron lo que consideraría escandaloso. Prest fue un paso atrás de db4o pero también fue maravilloso trabajar con él. "Simplemente funcionó" y fue rápido (aunque no tan bueno como para consultarlo). Sus licencias eran muy asequibles, pero algo en sus licencias era inaceptable para la (gran, conocida) corporación a la que contraía. Esto me lleva a donde estoy ahora ...

Answer 1

Bueno, ya que nadie más ha tratado de responder a esto, voy a echar mi opinión. Tenga en cuenta que nunca he usado protobuf (que es la razón por la que no he respondido ya), así que todo esto se basa solo en mi comprensión de las cosas y cómo, si tuviera que resolver este problema, procedería.

En primer lugar, tengo reservas sobre la colocación de blobs en una base de datos relacional. Esto puede regresar a mi forma de malas experiencias, muy atrás en los tiempos de la edad de piedra de VB6 y puede ser inválido, pero todavía me da pausa. Como tal, probablemente investigaría otros mecanismos de almacenamiento de objetos (como Perst o db4o) antes de intentarlo.

Como debida diligencia, al menos también perfilé blobs de relleno en una base de datos SQLCE. ¿Por qué SQLCE en lugar de SQlLite o algún otro RDMS? Bueno, porque SQLCE es compatible con TableDirect, que soy un gran fan de. Cada vez que puede acceder a los datos sin tener que usar un procesador de consultas lento, está muy avanzado.

Así que crearía una tabla, le daría un par de pequeñas columnas de búsqueda en las que podría buscar, luego una columna de imagen que contiene una gran mancha binaria (la burbuja real no es relevante para la prueba, pero necesita para estar razonablemente cerca de lo que espera en producción). Luego agregaría índices para cada una de las columnas de búsqueda.

Completaría la tabla con algunos miles de registros y luego perfilaré la velocidad a la que podría buscar la clave deseada (sé que es rápida) y más importante, la velocidad a la que puedo rehidratar mis objetos.

Luego ponderaría los costos (tiempo de desarrollo, costo de oportunidad, oportunidades de reutilización, etc.) de las opciones y tomaría la decisión. Probablemente también bloguee sobre los resultados, ya que parece ser un problema que sería bastante amplio.

Answer 2

No vi esto en ese momento (lo siento, pero no veo todas las preguntas, y mientras veo la etiqueta protobuf-net, no me quedo tan vigilante en protocol-buffers. Una pregunta muy interesante; términos de comparación a un documento base de datos (en lugar de relacional), creo que este tipo de enfoque tiene un gran potencial Parece un poco overkill mirando relacional si solo está cayendo blobs, pero debería funcionar al menos. Sin duda, utilicé configuraciones similares para la carga de datos en aplicaciones fuera de línea, no específicamente móvil, pero se aplican los mismos conceptos.

En particular, este tipo de enfoque centrado en documentos es útil cuando desea rehidratar "el sistema"; es decir, el estado completo. No son tan simples/flexibles de consultar ad-hoc como una base de datos relacional. Por supuesto, una opción es rehidratar y consultar en la memoria (por ejemplo, en C# la consulta LINQ-a-Objetos sobre datos rehidratados sería casi indistinguible de una consulta LINQ-a-SQL sobre los datos en una base de datos relacional)

Answer 3

Esa es una pregunta crucial si echa un vistazo a MariaDB 10 presentamos columnas dinámicas que almacenan una base de datos de objetos estructurados en un blob https://mariadb.com/kb/en/dynamic-columns/ Conversión desde el blob a lo que sea fácil para el cliente porque incorporamos API en el controlador C Creo que solo habilitamos la exportación json, pero con un pequeño esfuerzo, esto probablemente se pueda extender a protobuf serializado, deserializado.