¿Almacenar datos estáticos en una matriz o en una base de datos?

Question

Siempre tenemos algunos datos estáticos que pueden almacenarse en un archivo como una matriz o almacenarse en una tabla de base de datos en nuestro proyecto basado en web. Entonces, ¿cuál debería ser el preferido?

En mi opinión, las matrices tienen algunas ventajas:

1. más flexible (que puede ser cualquier estructura, que especifica una relación muy compleja)
2. Mejor rendimiento (se carga en memoria, que se han leído un mejor rendimiento/escritura en comparación con las operaciones de e/S de una base de datos)

Pero mi colega argumentó que prefería enfoque DB, ya que puede mantener una interfaz de persistencia de datos uniforme, y ser más flexible.

¿Cuál debería ser el preferido? ¿O cómo podemos elegir? ¿O deberíamos preferir uno en algún escenario y otro en otros escenarios? ¿Cuáles son los escenarios?

EDIT:

quiero aclarar algo. En verdad, al igual que Benjamin hizo el cambio al título, los datos que queremos almacenar en una matriz (archivo) no cambiarán con tanta frecuencia, lo que significa que el código no cambiará el valor de la matriz en el tiempo de ejecución. Si los datos cambian con mucha frecuencia, usaré DB sin dudas. Es por eso que hice una publicación así.

Y a veces es difícil de almacenar algunas relaciones muy complejas como:

Task = { 
    "1" : { 
    "name" : "xx", 
    "requirement" : { 
      "level" : 5, 
      "money" : 100, 
    } 
    ... 
} 

Al igual que el ejemplo de código anterior (un diccionario Python o se puede pensar como una matriz), el campo requisito es difícil de almacenar en DB (almacenar una estructura como objeto en escabeche directamente en DB? no tan bueno, creo). Entonces en tal condición, preferiré las matrices.

¿Cuál es su idea? En tal escenario, deberíamos preferir las matrices a DB, ¿verdad?

Atentamente.

Answer 1

Depende del tipo de datos que esté viendo y de si debe actualizarse regularmente.

Tiendo a mantener la mayoría de las cosas (datos no configurados) en la base de datos, incluso si los datos no se van a repetir (por ejemplo, thosands of rows). Las bases de datos se escalarán mucho más fácilmente que un archivo plano, si su sistema comienza a crecer rápidamente, su archivo plano podría convertirse en una carga para su sistema.

Answer 2

Si los datos no cambian muy a menudo, y su programación en Java, ¿por qué no utilizar Spring para guardar los valores?

Se pueden inyectar en su grano, y cambian fácilmente.

pero eso es si estás desarrollando en Java.

Answer 3

La matriz "flexible" en un archivo está cargada con un trillón de problemas que ya están relacionados con el uso de una base de datos. A menos que pueda probar que el DB realmente va mucho más lento que usar el otro enfoque, use un DB. Avanza y comienza a resolver problemas de negocios.

Editar

Comentario de OP le pregunta cuáles son los problemas con el uso de un archivo puede ser, aquí hay un puñado (pausa para tomar una respiración profunda).

• concurrencia: Usted tiene que gestionar la situación en la que múltiples peticiones pueden estar tratando de volver a escribir en el archivo. No es demasiado difícil, pero se convierte en un cuello de botella.
• Rendimiento: Sí, la modificación de una matriz en memoria es más rápida, pero ¿cómo se determina cuánto y cuándo se debe conservar la matriz en un archivo? Tenga en cuenta que el uso de un DB no excluye el uso de un caché en memoria apropiado. Escribir un archivo cada vez que se realiza una pequeña modificación no va a funcionar tan bien.
• Escalabilidad: Realmente una función de los dos primeros. Para alcanzar cualquier objetivo escalable, necesita poder modificar rápidamente pequeñas partes de los datos que persisten. IWO si no usas un DB terminarías escribiendo uno. Si encuentra que necesita más de un servidor web para soportar la creciente demanda, ¿dónde va a almacenar los archivos? Ahora tiene E/S de archivos en una red (es posible que sea muy rápida).
• Estructura: Su código será responsable de gestionar la estructura de datos, consultarla, etc., si utiliza una matriz. ¿Cómo lo hará de forma tal que obtenga una mayor "flexibilidad" que usar un DB? Todo tipo de elecciones y complejidad son necesarias aquí.
• Fiabilidad: Debe garantizar la integridad de sus datos persistentes. En caso de falla, su matriz/código de archivo necesitaría asegurarse de que los datos no estén tan corruptos como para que la aplicación pueda continuar.

Answer 4

Su colega está en lo correcto, PERO allí es donde debe dejar de lado el libro de texto de comp Sci y ser pragmático. ¿Con qué frecuencia accederá a estos datos desde su aplicación? Si es bastante frecuente, no incurra en los costos de acceso por sobrecarga. En lugar de leer desde un archivo plano, aún podría obtener las ventajas de un archivo db, pero use una estrategia de almacenamiento en caché en su aplicación. Dependiendo de su lenguaje de desarrollo, podría ver algo como memcache o jtreecache.

Answer 5

Sí, estoy de acuerdo con su evaluación implícita de que las bases de datos están sobreutilizadas y que los archivos planos básicos pueden funcionar en multitud de escenarios. Si su aplicación es de solo lectura (y las escrituras las realiza el administrador cuando se reinicia la aplicación) definitivamente iré con el archivo. Incluso si la aplicación escribe en el archivo, pero solo en el modo de adición (frente a las inserciones/actualizaciones aleatorias) en un hilo, también usaría el archivo. Cualquier otra cosa - necesita una base de datos real con actualizaciones, consultas, control de concurrencia al azar etc.

Answer 6

Permite ser pragmática/objetivo:

• se escribe a sus datos en tiempo de ejecución? Sí: Db, No: archivo
• ¿Actualizas tus datos más de una vez por semana? Sí: Db, No: Archivo
• ¿Es un dolor lanzar un archivo de datos actualizado? Sí: Db, No: Archivo,
• ¿Lee esos datos a menudo? Sí: Archivo/Caché, No: Db
• ¿Le duele actualizar ese archivo de datos y necesita herramientas adicionales?Sí: db, No: Archivo

Estoy seguro de que he olvidado otros puntos, pero creo que los fundamentos están ahí.