¿Cómo manejas pequeños conjuntos de datos?

Question

Con conjuntos de datos realmente pequeños, la política en la que trabajo es generalmente pegarlos en archivos de texto, pero en mi experiencia esto puede ser un dolor de cabeza de desarrollo. Los datos generalmente provienen de la base de datos y, cuando no lo hacen, el proceso involucrado en su configuración / almacenamiento generalmente está oculto en el código. Con la base de datos, generalmente puede ver todos los datos disponibles y las formas en que se relaciona con otros datos.

A veces, para conjuntos de datos realmente pequeños, simplemente los almaceno en una estructura de datos interna en el código (como un hash de Perl), pero cuando se necesita un cambio, está en manos de un desarrollador.

Entonces, ¿cómo maneja pequeños conjuntos de datos que cambian con poca frecuencia? ¿Ha establecido criterios sobre cuándo usar una tabla de base de datos o un archivo de texto o ...?

Estoy tentado de usar una tabla de base de datos para absolutamente todo, pero no estoy seguro de si hay alguna implicación en esto.

Editar: Para contexto:

Me han pedido que coloque un nuevo formulario de contacto en el sitio web para un puñado de empresas, y que se agreguen más ocasionalmente en el futuro. Excepto, las empresas no tienen direcciones de correo electrónico de contacto ... los usuarios dentro de estas compañías sí (ya que publican trabajos a través de sus propias cuentas). Ahora, sin embargo, queremos una "aplicación especulativa". escriba la funcionalidad y el formulario necesita una dirección de correo electrónico para enviar estas aplicaciones. Pero tampoco queremos poner una dirección de correo electrónico como una propiedad en la forma o los spammers pueden usarla como una puerta de enlace abierta. Claramente, necesitamos una identificación - > relación de tipo contact_email con empresas.

SO, puedo agregar una columna a una tabla con millones de filas que se usarán, literalmente, unas 20 veces O BIEN crear una nueva tabla que a lo sumo contendrá unas 20 filas. Normalmente, cómo manejamos esto en el pasado es simplemente crear un archivo de texto desagradable y leerlo desde allí. Pero esto crea pesadillas de mantenimiento y estos archivos de texto se revisan con frecuencia cuando los datos que dependen de los cambios. Quizás esto sea un error en el proceso, pero solo me interesa escuchar opiniones sobre esto.

Answer 1

Si se trata de datos de configuración pequeños, utilizo un formato simple y común. ini, json y yaml suelen estar bien. A los fans de Java y .NET también les gusta XML. en resumen, use algo que pueda leer fácilmente a un objeto en memoria y olvídese de él.

Answer 2

Ponlo en la base de datos. Si cambia con poca frecuencia, almacénelo en su nivel intermedio.

Answer 3

El ejemplo que viene a la mente de inmediato es lo que es apropiado tener almacenado como una enumeración y lo que es apropiado tener almacenado en una búsqueda " " tabla de base de datos.

Tiendo a " dibujar la línea " con la regla de que si da como resultado una columna en la base de datos que contiene un " número mágico " que se asigna a un valor de enumeración, entonces la enumeración debería existir realmente como una tabla de búsqueda. Si no está relacionado con los datos almacenados en la base de datos (por ejemplo, los datos de configuración de la aplicación en lugar de los datos generados por el usuario), entonces es una enumeración.

Answer 4

¿Seguramente depende del usuario de la herramienta de software que ha desarrollado para consumir el conjunto de datos, independientemente del tamaño?

Puede ser que conozcan Excel, por lo que su herramienta tendría que analizar un archivo .csv que ellos creen.

Si está escrito para los desarrolladores, a quién le importa lo que uses. Sin embargo, no soy un fanático de la saturación de bases de datos con datos menores o transitorios.

Answer 5

Tenemos un formato de archivo de configuración estándar (clave: valor) y una clase para manejarlo. Solo usamos eso en todos los proyectos. La mayoría de las veces, simplemente estamos configurando propiedades persistentes para nuestras aplicaciones (desarrollo de teléfonos móviles), por lo que es algo apropiado. YMMV

Answer 6

En los casos en que el programa accede a una base de datos, almacenaré todo allí: más fácil para hacer copias de seguridad y mover datos.

Para los programas pequeños sin acceso a la base de datos, almaceno mis datos en la configuración de .net, que se almacena en un archivo xml; por supuesto, esta es una función de c #, por lo que es posible que no se aplique a usted.

De todos modos, me aseguro de almacenar todos los datos en un solo lugar. Por lo general, una base de datos.

Answer 7

¿Ha considerado sqlite ? Está basado en archivos, lo que aborda su sensación de que "solo un archivo podría funcionar". (configuración cero), pero es una base de datos perfectamente buena y escala notablemente bien. Es compatible con una serie de API y hay numerosos frontends para administrarlo.

Answer 8

Lo agregaría a la base de datos en la tabla principal:

1. Copia de seguridad y recuperación (desea recuperar este archivo de texto, ¿verdad?)
2. Consulta adhoc (ya que puede hacerlo será una herramienta SQL y unirla a los otros datos de la base de datos)
3. Si la columna de la base de datos está vacía, los requisitos de la tienda para ella deberían ser mínimos (nada si es una columna NULA al final de la tabla en Oracle)
4. Será más fácil si desea tener múltiples servidores de aplicaciones, ya que no tendrá que mantener varias copias de algún archivo de configuración adicional alrededor
5. Ponerlo en una pequeña mesa infantil solo complica el diseño sin dar ningún beneficio real

Es posible que ya esté yendo a esa misma fila en la base de datos como parte de su procesamiento, por lo que es probable que el rendimiento no sea un problema. Si no lo está, puede guardarlo en la memoria.