Bases de datos versus texto sin formato

Question

Cuando se trata de proyectos pequeños, ¿cuál cree que es el punto de equilibrio para almacenar datos en archivos de texto simples, tablas hash, etc., frente a utilizar una base de datos real? Para proyectos pequeños con requisitos simples de administración de datos, una base de datos real es una complejidad innecesaria y viola YAGNI. Sin embargo, en algún punto, la complejidad de una base de datos vale la pena. ¿Cuáles son algunas señales de que su problema es demasiado complejo para técnicas ad hoc simples y necesita una base de datos real?

Nota: Para personas acostumbradas a entornos empresariales, esto probablemente parezca una pregunta extraña. Sin embargo, mi dominio de problema es la bioinformática. La mayor parte de mi programación son prototipos, no código de producción. Soy principalmente un experto de dominio y, en segundo lugar, un programador. La mayor parte de mi código está centrado en algoritmos, no centrado en la gestión de datos. El propósito de esta pregunta es, en gran medida, para mí determinar cuánto trabajo podría ahorrar a largo plazo si aprendo a utilizar bases de datos adecuadas en mi código en lugar de las técnicas más ad hoc que uso habitualmente.

Answer 1

1) Concurrencia. ¿Tiene varias personas accediendo al mismo conjunto de datos? Entonces, va a ser muy complicado involucrar a los diferentes lectores y escritores de una manera escalable si usted hace rodar su propio sistema.

2) Formateo y relaciones: ¿Son sus datos algo que no encaja perfectamente en una estructura de tabla? Largas secuencias de nucleótidos y cosas así? Eso no es realmente datos tabulares convenientemente.

Otro ejemplo: nadie consideraría implementar software como Photoshop para almacenar PSD en un formato relacional, porque las estructuras de datos realmente no se prestan a ese tipo de almacenamiento o patrón de consulta.

3) ÁCIDO (una especie de corolario del n. ° 1): si la atomicidad, la consistencia, la integridad y la durabilidad no son desafíos con un archivo plano, entonces vaya con un archivo plano.

Answer 2

Para mí, la línea se cruza una vez que tengo que consultar mis datos en formas que implican más de una relación. Relacionar dos estructuras de datos planas en el disco es bastante simple, pero una vez que logramos ir más allá, un lenguaje basado en conjuntos como el SQL y las relaciones de bases de datos formales realmente reducen la complejidad.

Answer 3

En software, generalmente puedo salirse con la tarea de almacenar valores en un archivo de configuración XML o en el registro, p. opciones de software. Una vez que necesito persistir en los objetos me desplazo a una base de datos porque el costo inicial no es tan malo en comparación con los efectos a largo plazo que las relaciones y los informes pueden ofrecer.

Answer 4

Para la bioinformática puede que le interese eso: Blast on DB. El tipo que está trabajando en eso es un amigo mío y tiene un trabajo en la búsqueda rápida de secuencia de similitud, descubrió que hacer su propio almacenamiento binario mejor que usar bases de datos en este punto.

No conozco detalles específicos sobre su solución, pero es probable que pueda intercambiar una o dos ideologías enviando por correo al chico, incluso compartiendo el código.

Answer 5

creo que en algún momento se perderá las capacidades de consulta de una base de datos, pero se puede considerar algunas alternativas de bases de datos minimalistas:

• SQLite (Gran, casi SQL-92 compatible con el estándar)
• shsql
• SQL Server Compact

Answer 6

emplear cualquier tecnología de persistencia que está más cómodo con, y escalas suffic iently.

YAGNI al menos significa "No agregue una nueva tecnología a su pila personal a menos que no pueda ser productivo con lo que ya está allí".

Para muchos (¿la mayoría?) De nosotros, nuestra zona de confort para la persistencia de datos es SQL. Para algunos, podría ser XML. Simplemente no escriba el suyo hasta (vea el párrafo 2).

Answer 7

Solo escribo mi propio formato en disco en circunstancias muy especiales. Reutilizar el código de otra persona casi siempre es más rápido.

Para datos relacionales, usaría SQLite. Para los pares clave/valor, usaría BerkeleyDB (quizás a través de KiokuDB). Para objetos simples, usaría JSON o YAML, pero solo si tuviera solo algunos.

Con SQLite y BDB, "una base de datos real" está literalmente a dos líneas de código. Es difícil vencer eso.

Answer 8

Como alguien que también está haciendo investigación en Bioinformática, sugiero NO utilizar una base de datos para este tipo de proyectos de prototipos a menos que esté seguro de que lo necesita. Si está en la mira, vaya con la solución sin base de datos y quédese con los archivos planos. También es importante tener en cuenta que, tradicionalmente, los investigadores de Bioinformática tienen la ruta de archivo plano, lo que significa que hay formatos de archivo bien definidos para la mayoría de los tipos de datos en el feild. Si decide utilizar una solución de base de datos, puede perjudicar su compatibilidad con los proyectos de investigación existentes.

Answer 9

¿Necesita/quiere consultas SQL?

¿Varias personas van a querer acceder a los datos?

¿Sus datos son relacionales?

Si contestó no a esas preguntas, probablemente no necesite una base de datos completa.

Answer 10

Depende completamente de las necesidades de la aplicación específica del dominio. Muchas veces el acceso directo a archivos de texto/archivos binarios puede ser extremadamente rápido y eficiente, además de brindarle todas las capacidades de acceso a archivos del sistema de archivos de su sistema operativo.

Además, su lenguaje de programación probablemente ya tenga un módulo integrado (o sea fácil de hacer uno) para el análisis específico.

Si lo que necesita son muchos anexos (¿INSERTOS?) Y secuencial/pocos acceden poco/nada, los archivos son el camino a seguir.

Por otro lado, cuando sus requisitos de concurrencia, lectura/escritura no secuencial, atomicidad, permisos atómicos, sus datos son relacionales por naturaleza, etc., estará mejor con una base de datos relacional o OO.

Hay mucho que se puede lograr con SQLite3, que es extremadamente ligero (menos de 300kb), cumple con ACID, está escrito en C/C++ y es muy ubicuo (si no está incluido en su lenguaje de programación -for ejemplo Python-, seguramente hay uno disponible). Puede ser útil incluso en archivos db de hasta 1 GB o más.

Si sus requisitos son mayores, ni siquiera se discutirá, opte por un RDBMS completo.

Answer 11

El problema con los proyectos pequeños es que crecen antes de que nos demos cuenta. Y una vez que lo hacen, comenzamos a perder las capacidades sql.

Diseñe siempre de modo que una base de datos se pueda utilizar más adelante si es necesario sin desgarrar la mitad de la aplicación.

Answer 12

En primer lugar, me gustaría considerar:

1. ¿Qué tan grande será inicialmente la base de datos: número de mesas, # de filas
2. ¿Qué tan rápido va a crecer?
3. ¿Los datos son frecuentemente consultados?

Si tuviera que crear una aplicación de recetas personal, por ejemplo, sé que podría agregar 50 recetas favoritas para comenzar y agregar no más de 5 recetas al año. Habiendo dicho eso, podría salir adelante sin una base de datos, ya que el tamaño del almacén de datos tendrá un impacto mínimo en las consultas.

Dicho esto, probablemente utilizaría una base de datos para cualquier aplicación en la que se produzcan entradas de datos y consultas (incluso una pequeña aplicación de recetas personal). No creo que agregue muchos sobrecargas, especialmente cuando su marco (por ejemplo, Rails) le permite mantener su base de datos tonta (principalmente tablas, índices y restricciones). Alivia la posibilidad de que eventualmente tenga que ingresar a una base de datos si decido ampliarla.

Answer 13

Si conoce el formato de sus datos, los archivos planos, si son más rápidos/fáciles de desarrollar, estarán bien. Si espera que sus formatos de registro cambien con frecuencia durante el desarrollo, le sugiero que ALTER TABLE sea su amigo. Los archivos planos también tenderán a ser más rápidos (si le importa la velocidad) a menos que espere implementar el equivalente de combinaciones en muchas combinaciones de archivos.

La ventaja real de utilizar un RDBMS durante el desarrollo es la flexibilidad con la que puede modificar su esquema de datos y la facilidad con la que puede acceder a sus datos mediante consultas.

El buen diseño asegurará que mantenga su capa de acceso a los datos relativamente aislada (debido a la separación de las preocupaciones) por lo que debería ser una tarea bastante sencilla (aunque tediosa) volver a trabajar en una base de datos si fuera necesario. O, por supuesto, si usa una base de datos para desarrollar sus estructuras, puede volver a llevar la aplicación a archivos planos/indexados una vez que esas estructuras se cristalizan para obtener rendimiento.

Answer 14

Para el tipo de aplicaciones que está desarrollando en bioinformática, a menudo está haciendo aplicaciones únicas (a menudo scripts que definen un flujo de trabajo de cálculos) que responden a preguntas específicas, y no es probable que reutilice estas aplicaciones después usted respondió su pregunta
A menudo, debe evitar crear bases de datos para almacenar los resultados, ya que, después de todo, no va a utilizar mucho sus características.

Probablemente esté consultando algunos servicios web, archivos o bases de datos, ejecute algunos algoritmos locales sobre los datos recopilados de diferentes fuentes y produzca algún formato de salida tabulado o estructurado (xml, json, etc.).

Por eso, les sugeriría a utilizar herramientas de flujo de trabajo como Knime (o una solución comercial como Inforsense KDE, Accelrys de Pipeline pilot o Snaplogic, ya que le permiten consultar datos en una variedad de formatos y ubicaciones (RDBMS, archivos planos , servicios web), ejecute algoritmos y cree poderosas aplicaciones web que le permitan publicar fácilmente sus flujos de trabajo a sus usuarios y permitirles interactuar en puntos específicos).

Si su prototipo "crece" y tiene que crear más funcionalidades sobre los datos que generan sus flujos de trabajo, y si es probable que la salida de su prototipo no cambie todos los días, entonces es una buena decisión almacenar un subconjunto de los resultados en una base de datos. Esto le permite conectar potentes herramientas de informes como BusinessObjects, informes de Crystal, informes de jaspe o cualquier otra solución de informes disponible y mostrar datos a sus usuarios en una mejor forma que una hoja de cálculo o un archivo csv.

Finalmente, algunos frameworks de desarrollo harán sus elecciones más obvias: si construye una aplicación web usando un framework MVC, es probable que sus datos residan en un RDBMS (pero por favor, no ponga secuencias genómicas en un columna de la tabla :-)).

En general, es una opción caso por caso, dependiendo de sus necesidades para cada aplicación en particular.