¿Es malo no usar un DB pero usarlo en objetos de memoria?

Question

Me han encargado que escriba una pequeña aplicación para ser utilizada por un solo usuario. Esta aplicación obtendrá ~ 500 nombres/departamentos de empleados de nuestro DB maestro de empleados. Luego, el usuario ingresará como 5 campos para cada empleado. Esos 5 campos generalmente solo cambiarán una vez al año, pero podría ser el peor caso una vez al mes. Solo se supone que debo hacer un seguimiento de 2 años en cualquier momento dado.

He mirado SQLite y SQL CE y no me entusiasman ninguno de ellos. SQL CE no quiere permitir que el archivo de datos resida en un recurso compartido de red. (Solo un usuario único, pero almacenan todos sus documentos en su recurso compartido privado que se respalda diariamente).

Parece que SQLite encajaría mejor pero no se integra tan bien en Visual Studio sin envoltorios ni nada.

La otra cosa a tener en cuenta es que nuestra gente está versada en MS SQL Server y poco más, por lo que tener algo que entiendan frente a SQLlite será algo importante para mi jefe.

Así que mi pregunta es: ¿Qué sucede si guardo los datos en Objetos en la memoria y los serializo en el disco al guardarlos? Hice una prueba rápida y con 10k personas (nuestro uso será solo 500-1000 máximo) y 10 años cada uno (o 10 meses si actualizan sus datos cada mes, muy poco probable) solo causó que mi aplicación de demostración usara 30 MB de memoria. También llenando esos datos fue instantáneo incluso con el uso de GUID's para llenar aleatoriamente todas las cadenas. ¿Es una mala idea? Es una aplicación bastante simple y en este caso me parece bien.

Answer 1

veo algunos problemas con la idea de la persistencia de los datos de negocio utilizando la serialización de objetos:

Estos no son necesariamente show-tapones para la idea, sino más bien algo en que pensar ...

1. Los datos no pueden ser consultados, informados o inspeccionados. La aplicación lo captura de forma totalmente opaca.
2. La depuración de datos serializados es más difícil que poder ver los datos correspondientes en una base de datos, o incluso un formato como CSV.
3. No hay atomicidad: es posible corromper toda su "base de datos" con una falla de energía o un bloqueo de la aplicación.
4. Si el modelo de datos cambia, actualizar las entidades persistentes existentes requiere una versión de la aplicación que pueda leer tanto el formato antiguo como el nuevo. Con una base de datos, puede simplemente agregar una columna (o sub tabla).
5. No hay una manera clara de implementar el acceso concurrente. ¿Qué sucede si más de un usuario desea ver o editar los datos?

Una cosa que he aprendido, es que las aplicaciones pequeñas tienden a crecer y convertirse en "grandes aplicaciones". Cuando las organizaciones adivinan incorrectamente sobre el valor potencial de una aplicación, tienden a incurrir en los costos de este tipo de crecimiento orgánico inesperado más adelante.

También menciona que le gustó en SQLLite y no le gustó. ¿Qué es lo que no te gustó? ¿Qué tipo de problemas anticipaste?

Si solo está buscando una forma de "cortar esquinas" para hacer esto más rápido - eso puede estar bien a corto plazo - pero tenga cuidado - este tipo de decisiones tienen forma de volver a morderlo.

Answer 2

Por serializar los datos se pierde:

• búsqueda de estilo SQL
• capacidad de insertar/actualizar/borrar registros individuales
• bien conocido y comprendido
• no un lenguaje específico
• accesibilidad para otras aplicaciones y no locales

Ganas

• fácil
código
• simple copia de seguridad (asegúrese de que usted ha pensado en la copia de seguridad!)
• un menor número de dependencias

Desde su descripción de sus objetivos y limitaciones que puedo' Ver cualquier problema específico con su enfoque.

Otra idea. Parece que está guardando una estructura de datos simple similar a una tabla, por lo que le recomendamos guardarla en una forma legible para los humanos, como un archivo de valores separados por comas o incluso XML. De esta forma, no dependes del idioma que estás usando actualmente.

Answer 3

Sus propias pruebas muestran que debería funcionar. Sin embargo, le sugiero que abstraiga su capa de datos para que, si necesita ser reemplazada, pueda hacerlo de manera rápida y fácil. Si encuentra que desea solo una pista de SQL con sus objetos, puede mirar Linq to Objects

Answer 4

A lo largo de los años he visto muchas aplicaciones pequeñas que deben ser utilizadas por un solo usuario. (Durante mucho tiempo, todos tenían acceso a back-ends por alguna razón). Invariablemente se convierten en aplicaciones grandes utilizadas por varios usuarios.

Pero la verdadera pregunta no es qué tan grande va a ser, sino cómo se usarán los datos. Normalmente, las personas almacenan datos porque luego quieren ver los datos, y eso generalmente significa informes, y eso significa que un sistema de base de datos relacional sería algo asombroso.

Answer 5

Almacenar los datos en la base de datos tiene otros beneficios, como leer los datos de otra aplicación o desde un simple editor de base de datos. Si alguna otra aplicación en el futuro desea reutilizar los datos será más fácil de hacer que deserializar desde un objeto java. También debe lidiar con el control de versiones de los objetos y la consulta será difícil si la usa con objetos java.

Answer 6

Si los datos originales están en SQL Server en los que carga, ¿no intentará uno de los users versed in MS' SQL Server SELECCIONAR los cambios que está realizando su aplicación? Si lo guardas en otro lugar, nunca lo encontrarán.

¿Cómo va a almacenar estos datos algo diferente de la base de datos original para ayudar a la empresa? ¿O obstaculizará el negocio? tienes que decidir eso, y luego resolver el problema desde allí. No sobre cómo es más fácil/mejor para mí hacer esta tarea.

Answer 7

¡Guarde sus datos en una base de datos! Desacoplarlo usando una capa de datos. Puede usar un ORM si lo desea o solo un repositorio simple y antiguo, pero nunca use un archivo de texto, un archivo xml, un archivo json para almacenar ese tipo de información.

Puede usar SQL Server si lo tiene, lo usa, está ahí por algún motivo.

Answer 8

Si usted puede almacenar estos 5 campos de datos adicionales en la base de datos maestra, entonces eso parecería ideal.

Si no puede, probablemente podría simplemente darles un archivo de Excel con algún tipo de extensión o macro para obtener datos de la base de datos. Excel le brinda muchas funciones conocidas para impresión, clasificación, gráficos, etc. No nos ha dicho mucho sobre lo que debería hacer la aplicación además de actualizar estos 5 campos.

Si está decidido a escribir una aplicación .net para esto, y no usar un DB, al menos ponga sus datos en formato XML utilizando la serialización XML.

Answer 9

Por su justificación, sin duda puede utilizar el archivo, pero me parece que con un servidor de base de datos, será más extensible. A menudo comenzamos con un proyecto que creemos que conocemos todos sus requisitos y nunca cambiará, pero la realidad no lo es. En su diseño, si un usuario solicita un campo adicional, deberá personalizar su código nuevamente para tratar con el campo binario/longitud fija serializada. SQLite tiene un buen soporte e incluso son proveedores de LinQ.

Creo seriamente que una solución más fácil para implementar su proyecto para el requisito anterior es crear un formulario de acceso. Defina el campo y luego use el asistente para crear el formulario en el acceso. Con muy poco esfuerzo, puede implementar toda esta tarea teniendo en cuenta la extensibilidad.