serialización vs base de datos

Question

Creo que la mejor manera de guardar el estado de su aplicación es una base de datos relacional tradicional que la mayoría de las veces su estructura de tabla representa más o menos el modelo de datos de nuestro sistema + metadatos.

Sin embargo, otros miembros de mi equipo piensan que hoy en día es mejor simplemente serializar todo el gráfico del objeto en un archivo binario o XML.
No hace falta decir (pero aún lo diré) que la Tercera Guerra Mundial va entre nosotros y me gustaría escuchar su opinión sobre este tema.

Personalmente odio serialización porque:

1. Los datos guardados se adhiere sólo a su plataforma de desarrollo (C# en mi caso). Ninguna otra plataforma como Java o C++ puede usar esta información.
2. Se guarda el gráfico completo de objetos (incluida toda la cadena de herencia) y no solo los datos que necesitamos.
3. Cambiar el modelo de datos puede causar graves problemas de compatibilidad con versiones anteriores al intentar cargar estados anteriores.
4. Compartir partes de los datos entre aplicaciones es problemático.

Me gustaría conocer su opinión al respecto.

Answer 1

Consulte this Stackoverflow posting para obtener un comentario sobre la aplicabilidad de XML frente a la aplicabilidad de un sistema de gestión de bases de datos. Discute un problema que es bastante similar al tema del debate en su equipo.

Answer 2

Tiene algunos puntos buenos. Estoy más o menos de acuerdo contigo, pero haré de abogado del diablo.

1. Bueno, siempre se puede escribir un convertidor en C# para extraer los datos más adelante si es necesario.

2. Ese es un punto débil, porque el espacio en disco es barato y la cantidad de bytes adicionales que utilizaremos cuesta mucho menos que el tiempo que desperdiciaremos tratando de hacer que todo funcione a su manera.

3. Esa es la manera del mundo. Grabe los puentes y requiera actualizaciones. Convierta los datos, o cree una herramienta para hacer eso, y luego deje de ser compatible con la forma de hacerlo de la versión anterior.

4. No si el programa C# pasa los datos a las otras aplicaciones. Otras aplicaciones no deberían tener acceso a los datos que pertenecen a esta aplicación directamente, ¿verdad?

Answer 3

Para la transferencia y el almacenamiento fuera de línea, la serialización está bien; pero para uso activo, es preferible algún tipo de base de datos.

Normalmente (como dices), sin una base de datos, necesitas deserializar toda la secuencia para realizar cualquier consulta, lo que hace que sea difícil escalar. Agregue los problemas inherentes al roscado, etc., y está pidiendo dolor.

Algunos de sus otros puntos negativos acerca de la serialización no son todos ciertos, siempre y cuando elija con prudencia. Obviamente, BinaryFormatter es una mala elección para portability and versioning, pero "protocol buffers" (formato de serialización de Google) tiene versiones para Java, C++, C# y lot of others, y está diseñado para ser tolerante a la versión.

Answer 4

Depende de lo que desea serializar, por supuesto. En algunos casos, la serialización es ridículamente fácil.

(Una vez escribí un tipo de programa de línea de tiempo en Java, donde podías dibujar arrastrar y cambiar el tamaño de los objetos. Si estabas listo podías guardarlo en un archivo (como myTimeline.til). En ese momenet cientos de donde los objetos salvados, su posición en el lienzo, su tamaño, sus colores, sus innertexts, sus efectos especiales, ...

Usted podría por supuesto que abrir myTimeLine.til y trabajar más.

Todo esto sólo se les pide a pocas líneas de código. (acaba de hacer todas las clases y sus dependencias serializable) y mi tiempo de codificación tomó menos de 5 minutos, ¡estaba asombrado! (era la primera vez que usaba serialización alguna vez)

Al trabajar en una línea de tiempo, también podía 'guardar como' para diferentes versiones y los archivos 'til' eran muy fáciles de hacer copias de seguridad y enviar por correo.

Creo que en mi caso particular sería un poco idiota usar bases de datos. Pero eso es por supuesto solo para estructuras tipo documento, como Word para nombrar una.)

Mi punto es lo primero: hay ciertamente varios escenarios en los que las bases de datos no serían la mejor solución. La serialización no fue inventada por los desarrolladores solo porque estaban aburridos.

1. No es cierto si se utiliza XMLserialization o SOAP
2. No es muy relevante ya
3. Sólo si no está cuidado, un montón de 'mejores prácticas' para eso.
4. Sólo si usted quiere que sea problemático, ver 1

Por supuesto serialización tiene además de la velocidad de aplicación otras ventajas importantes, como no tener una base de datos en absoluto en algunos casos!

Answer 5

No dijo qué tipo de datos es, depende mucho de su rendimiento, simultaneidad, instalación, seguridad, disponibilidad y requisitos de centralización.

• Si estos datos son muy grandes (por ejemplo, muchos casos de los objetos en cuestión), una base de datos puede mejorar el rendimiento a través de sus capacidades de indexación. De lo contrario, probablemente perjudica el rendimiento o es indistinguible.

• Si su aplicación está siendo ejecutada por varios usuarios simultáneamente, y es posible que quieran escribir estos datos, una base de datos ayuda porque puede confiar en las transacciones para garantizar la integridad de los datos. Con la persistencia basada en archivos, debe manejarlo usted mismo. Si los datos son de usuario único o instancia única, es muy probable que una base de datos sea excesiva.

• Si su aplicación tiene su propia instalación de sopa a nueces, usar una base de datos supone una carga adicional para el usuario, que debe configurar y mantener (aplicar parches, etc.) el servidor de la base de datos. Si se puede garantizar que la base de datos está disponible y es manejada por otra persona, esto no es un problema.

• ¿Cuáles son los requisitos de seguridad para los datos?Si los datos están centralizados, con múltiples usuarios (simultáneos o secuenciales), es posible que deba administrar la seguridad y los permisos sobre los datos. Sin ver los datos, es difícil decir si sería más fácil de administrar con persistencia basada en archivos o una base de datos.

• Si los datos son solo locales, muchas de las preguntas anteriores sobre los datos tienen respuestas que apuntan hacia la persistencia basada en archivos. Si necesita acceso centralizado, las respuestas generalmente apuntan hacia una base de datos.

Mi conjetura es que es probable que no necesita una base de datos, basándose únicamente en el hecho de que usted está pidiendo al respecto sobre todo desde una perspectiva de programación de conveniencia y no la perspectiva de los requisitos de datos. La serialización, especialmente en .NET, es altamente personalizable y se puede adaptar fácilmente para que persista solo las piezas esenciales que necesita. Hay well-known best practices para versionar estos datos también, así que no estoy seguro de que haya una ventaja en el lado de la base de datos desde esa perspectiva.

Acerca de las preocupaciones de plataformas cruzadas: si no sabe para cierta que se requerirá la funcionalidad multiplataforma en el futuro, no la cree ahora. Es casi seguro que es más fácil resolver ese problema cuando llega el momento (migración, etc.) que restringir su desarrollo ahora. La mayoría de las veces, YAGNI.

Acerca del intercambio de datos entre las partes de la aplicación: debe estar estructurado en la propia aplicación, p. en las clases que acceden a los datos. No sobrecargue el mecanismo de persistencia para que también sea un conducto de datos entre las partes de la aplicación; si lo sobrecarga de esa manera, está convirtiendo el estado persistente en un contrato de objeto cruzado en lugar de tratarlo adecuadamente como una extensión del estado privado del objeto.

Answer 6

Solo asegúrese de tener un componente que maneje el estado de guardar/cargar con una interfaz limpia para el resto de su aplicación. Entonces, cualquiera que sea la elección que haga para la persistencia puede volver a visitarse fácilmente más adelante.

La serialización de un gráfico de objeto en un archivo puede ser una buena solución inicial rápida y sucia que es muy rápida de implementar.

Pero si comienza a encontrarse con problemas que hacen que una base de datos sea una mejor opción, puede conectar una nueva versión con poco o ningún impacto en el resto de la aplicación.

Answer 7

Sí propably true. La desventaja es que debe recuperar el objeto completo, que es como recuperar todas las filas de una tabla. Y si es grande, será un inconveniente. Pero si no es tan grande y con mis proyectos de hobby no lo son, ¿entonces deberían ser una pareja perfecta?