En desarrollo ágil, ¿debería intentar la persistencia en el archivo plano antes de la base de datos?

21

Alguien me explicó que, dado que en el desarrollo ágil, la política y la lógica de la aplicación deberían ser más importantes que los detalles como el método de persistencia, la decisión de persistencia debería tomarse al final. Por lo tanto, podría ser una buena idea comenzar con una persistencia más simple, como archivos planos, hasta que lleguemos al punto en que la debilidad de este método sea evidente, y solo entonces cambiemos la persistencia, por ejemplo, utilizando una base de datos relacional.

¿Es esto cierto o entendí mal el concepto? ¿Es así como el equipo ágil suele crear aplicaciones? ¿Cuáles son las razones para ello y cuándo no debería adoptar este enfoque?

Louis Rhys
fuente
1
La lógica de persistencia no es parte de detalles menores, o menos importante. Esa debe ser la primera decisión. Desea propiedades ACID para su estructura de persistencia. Esa decisión no puede quedar pendiente.
Manoj R

Respuestas:

42

El concepto que se transmite es algo que definitivamente forma parte de lo ágil y relevante, la idea de llevar las cosas al último momento responsable.

Sin embargo, el ejemplo tomado en realidad se basa en una suposición completamente falsa para comenzar:

que es más fácil / menos trabajo implementar una base de datos de archivo plano que usar un RDBMS. - A menudo completamente falso

El ejemplo debería ser: la capa de persistencia se mantiene con la implementación más simple posible hasta que se decida que es inadecuada.

Para muchos equipos de desarrollo, obtener una base de datos para hacer esto es cuestión de una o dos horas (o 15 minutos para una base de datos pequeña con ORM), mientras que una base de datos de archivo plano con la que no necesitan entrometerse puede ser una enorme molestia y molestia porque tienen que escribir a mano todo el código de tipo de búsqueda y construcción de tabla de datos manualmente, cuando una base de datos puede ser tan simple como crear una tabla en una interfaz de usuario, agregar algunas columnas y luego hacer que un ORM genere todo más lo necesitas

Además, si no conoce su capa de persistencia para comenzar, es un acto aún más apropiado comenzar con un RDBMS común que su equipo conoce bien, ya que hacer el cambio más tarde de archivo plano a RDBMS es mucho más grande que más tarde cambiando de un RDBMS a otro. Hay muchas herramientas para convertir de la mayoría de los RDBMS comunes a otros, y consejos y cosas por el estilo, ya que es una ruta muy transitada. Hay muy pocas herramientas para convertir un archivo plano a cualquier RDBMS dado en el que su archivo plano tiene algún formato propietario para el que las herramientas no se han escrito previamente aparte de sus propias bibliotecas.

En resumen: el concepto es correcto y preciso, pero el ejemplo se basa en una suposición terriblemente grande y a menudo (casi siempre) inexacta .

Jimmy Hoffa
fuente
66
¡Y su suposición terriblemente grande es que tienen que escribir a mano todo el código de tipo de construcción de búsqueda y tabla de datos manualmente! :-) Por lo general, cuando utiliza un archivo plano, comienza utilizando el formato de serialización incorporado en su idioma (por ejemplo, Marshal en Ruby o NSKeyedArchiver en Cocoa / Objective-C) y simplemente descarga algunos objetos internos existentes. Siempre que su aplicación no tenga que recargarse con demasiada frecuencia, y siempre que controle los cambios de esquema en las versiones de la aplicación, esta técnica puede funcionar notablemente bien durante mucho tiempo, especialmente durante el desarrollo.
Alex Chaffee
@AlexChaffee es un punto justo, pero de cualquier manera necesita escribir algo de código alrededor de estas cosas de una manera u otra y los ORM modernos hacen que hacer esas cosas con un RDBMS o NoSQL sea bastante trivial, donde la diferencia en el impacto en el equipo es basado más en el conjunto de habilidades de los equipos que en cualquier otra cosa, creo que es un mal ejemplo para ilustrar el punto que está tratando por esta razón. Personalmente, he usado MSSQL durante 13 años, pero ponerlo en el lugar haría girar a MongoDB por persistencia debido a la simplicidad de no dejar que afecte el objetivo real del proyecto hasta que ACID importara.
Jimmy Hoffa
17

Como sabe que usará una base de datos, no tiene mucho sentido escribir código para manejar archivos planos. Puede pasar por algunas iteraciones usando algunos CSV de solo lectura, pero rápidamente se encontrará escribiendo código que sabe que tirará.

Una cosa que puede hacer para simplificar la complejidad inicial mediante el uso de algo como SQLite (una biblioteca que le brinda una base de datos SQL sin servidor que se almacena en un archivo). Tiene un sistema de tipo flexible para que no tenga que comprometerse seriamente con un esquema, ningún servidor para configurar / conectarse y reconstruir su base de datos es tan simple como eliminar un archivo. También le permite incluir simplemente la imagen de la base de datos junto con el código en el control de versiones si es necesario.

Sean McSomething
fuente
44
Parece que recibió un voto negativo de la Flat File Society.
JeffO
@JeffO: SQLite guarda su base de datos en un archivo plano.
Mr.Mindor
77
@ Mr.Mindor, la mayoría de las bases de datos sí ... pero eso es irrelevante. 'Archivo plano' aquí significa manipular directamente el archivo, en lugar de pasar por una capa de base de datos.
GrandmasterB
Discrepar. Todavía necesitaría aprender cómo funciona SQLite e implementar código que manipule la base de datos SQLite en .NET, convierta el resultado de la consulta en objetos, etc. para que no facilite el desarrollo. Simplemente agrega todas las cargas de crear una base de datos, sin las ventajas de un servidor de base de datos completo.
Louis Rhys
11

Es un ejemplo, utilizado para demostrar un concepto, en lugar de un concepto en sí mismo.

El concepto es que no tome una decisión arquitectónica hasta el último momento responsable , pero no más tarde. Pero, en realidad, a menudo tienes una decisión sobre la base de datos que vas a usar desde el principio. Puede que no sea perfecto, pero es un hecho.

Una vez que se toma esa decisión, no la evitas activamente. Almacenar algo en una base de datos existente es a menudo tan fácil como almacenarlo en un archivo plano.

Pero cambiar de MySql en Linux a SQL Server en Windows podría no ser tan simple como cambiar de un archivo plano en cualquier lugar a SQL Server en Windows. Ese es el verdadero punto. Entonces, si bien hay dudas sobre la solución final, tome la opción más simple posible, teniendo en cuenta el cambio. Una vez que se toma una decisión, cúmplala.

pdr
fuente
No estoy de acuerdo con la ruta de migración. technet.microsoft.com/en-us/library/cc966396.aspx tiene instrucciones detalladas sobre la migración de MySQL a MSSQL, aunque para convertir un archivo plano en cualquiera de las opciones requeriría escribir manualmente algunos ETL en SSIS o la versión de MySQL.
Jimmy Hoffa
@JimmyHoffa: No sé, un CSV es bastante fácil. blog.sqlauthority.com/2008/02/06/… tech-recipes.com/rx/2345/import_csv_file_directly_into_mysql pero entiendo que ninguno de los dos caminos es TAN complicado.
pdr
6

¿Qué persiste?

Estoy en un equipo ágil y para una aplicación, persistimos casi todo en la base de datos. Eso sí, si no lo hiciéramos, entonces esta aplicación no tendría mucho que hacer: persistir en una base de datos es una gran parte de su razón de ser .

Entonces: ¿Qué persiste y qué hace su aplicación? Si a la aplicación no le importa dónde persisten sus datos, puede escribir una pequeña capa que tome la decisión (esa decisión puede almacenarse en un archivo de configuración en algún lugar) de archivo plano frente a base de datos. Creo que se necesita para evaluar su aplicación y sus datos y decidir si tiene sentido en el caso específico de invertir tiempo en la persistencia de base de datos, o simplemente leer / escribir archivos planos (que será probablemente ser más rápido en términos de tiempo de desarrollo).

FrustratedWithFormsDesigner
fuente
1
La aplicación gestiona una cola de solicitudes, y necesita recordar la cola después de cerrar y reiniciar ... no hay obligación de usar la base de datos como en su aplicación
Louis Rhys
@LouisRhys: ¿Qué se hará con estos datos de la cola? ¿Simplemente leer y mostrar al usuario? ¿Qué beneficios cree que obtendrá de persistir en una base de datos?
FrustratedWithFormsDesigner
Se ejecutarán las acciones en la cola. El beneficio de la base de datos incluye rendimiento, gestión de concurrencia, y probablemente el cliente también se preocupará por la seguridad, la legibilidad y la consulta de datos.
Louis Rhys
@LouisRhys: Tal vez para la primera o dos iteraciones de desarrollo podría usar un archivo plano, solo para obtener una prueba de concepto que funcione, pero es posible que desee separar por completo la lógica del acceso a los datos, ya que en el futuro Parece que una base de datos podría ser algo bueno (y cambiar de archivo a db tardará más tiempo). En última instancia, esta es una decisión de arquitectura avanzada que solo usted puede tomar ya que tiene acceso a las especificaciones / requisitos del cliente.
FrustratedWithFormsDesigner
5

Mucha gente malinterpreta ese aspecto de ágil, lo que significa que no deberían planificar con anticipación las características futuras. Nada mas lejos de la verdad. Lo que no debe hacer es permitir que la planificación de funciones futuras retrase la entrega de valor a sus clientes ahora.

Cómo se aplica eso a algo como la persistencia depende mucho de su aplicación. Uno de mis proyectos de hobby actuales es una calculadora. Eventualmente, me gustaría poder almacenar constantes y funciones definidas por el usuario, y guardar el estado cuando cierre el programa. Eso requiere persistencia, pero ni siquiera he comenzado a pensar qué forma tomaría. Mi programa será muy útil sin persistencia, y agregarlo ahora agregará un retraso significativo a mi primer lanzamiento. Prefiero tener una calculadora que funcione con menos funciones que ninguna mientras espero que sea perfecta.

Otro proyecto hobby mío es para la corrección de color de video y fotografía. Esta aplicación será completamente inutilizable sin poder guardar mi trabajo en progreso, y el código necesario para hacerlo es omnipresente en todo el programa. Si no lo hago bien desde el principio, cambiarlo podría ser prohibitivamente difícil, por lo que he dedicado bastante esfuerzo a la persistencia por adelantado.

La mayoría de los proyectos se encontrarían en algún punto intermedio, pero nunca debería sentirse mal por planificar futuras funciones si agrega poco o ningún esfuerzo adicional ahora. Las bases de datos pueden ser complejas, pero la mayor parte de esa complejidad está oculta detrás de una interfaz sólida y bien probada. El trabajo que tendrá que hacer en su aplicación puede ser menos para una base de datos que un archivo plano, debido a todas las características que una base de datos le brinda de forma gratuita. Hay opciones "híbridas" como SQLite si aún no desea lidiar con la molestia de un servidor de base de datos.

Karl Bielefeldt
fuente
1
"Los planes son inútiles, pero la planificación es esencial". - Eisenhower
Alex Chaffee
3

Creo que te estás enfocando en los valores incorrectos. En ágil, el valor empresarial está en foco. Usted crea un producto para entregar valor comercial a algunos usuarios finales.

Si crea la capa de persistencia tarde, o la inventa en el camino, es su estrategia para entregar valor comercial al cliente. No creo que el término "ágil" en sí mismo dicte si debe hacer uno u otro.

El punto de vista sobre el aplazamiento de la estrategia de almacenamiento de datos se aboga en esta presentación por Robert C. Martin (uno de los autores del manifiesto ágil).

Es una muy buena presentación, puedo recomendar que la vean.

Pero no estoy de acuerdo con eso! Al menos hasta cierto punto.

No creo que pueda llamar a una historia de usuario para "Hecho", si la historia de usuario involucra datos que deberían persistirse, y en realidad no tiene implementado ningún tipo de persistencia.

Si el propietario del producto decide que ahora es el momento de ponerlo en funcionamiento, no puede hacerlo. Y si no ha comenzado a implementar la persistencia hasta el final del proyecto, tampoco tiene información sobre cuánto tiempo tomaría implementar la capa de persistencia, lo que lo convierte en un riesgo importante para el proyecto.

Los proyectos ágiles en los que he trabajado no han diferido la estrategia de acceso a datos. Pero se ha desacoplado, lo que nos permite cambiarlo en el camino. Y el esquema completo de la base de datos no está diseñado por adelantado. Las tablas y columnas se crean a lo largo del camino a medida que se requieren para implementar el usuario almacenado que, al final, brinda valor comercial.

Pete
fuente
1

Se necesita buen juicio y experiencia para ver qué preguntas deben responderse primero al embarcarse en un nuevo proyecto.

Si el producto final aún se desconoce, entonces la construcción / creación de prototipos rápidamente lo ayudará a resolverlo, y sí, iterar de manera ágil ayudará. Eso, por supuesto, introducirá riesgos, como descubrir al final del proceso que la implementación de persistencia llevará más tiempo del que comunicó a sus partes interesadas.

Si el producto final es bien conocido, comprender cómo funcionará la persistencia en su aplicación podría ser más importante para saber desde el principio. El riesgo es que encuentre problemas con la especificación de su producto más adelante en el proceso de desarrollo.

Robert Watts
fuente
0

¡Los archivos planos no son simples!

Permiten almacenamiento y eso es todo. La estructura de los datos, las rutas de acceso, etc., dependen de usted y hay muchas maneras de equivocarse.

Existen razones por las que existen bases de datos y una de ellas es hacer las cosas más simples para los desarrolladores.

La mayor parte de mi desarrollo se realiza para grandes sistemas dentro de grandes empresas. Siempre tenemos un modelo de datos completo y bien pensado antes de continuar con cualquier diseño o desarrollo adicional. Un modelo de datos lo ayuda a comprender su problema y permite una implementación limpia.

Los elementos de datos olvidados, las estructuras de datos no coincidentes y otras pesadillas pueden evitarse mediante la producción de un modelo de datos por adelantado.

Puede dejar su elección real de tecnología de base de datos hasta después del modelo de datos. Pero la mayoría de las tecnologías de "persistencia" están estrechamente ligadas a la programación e incluso a los estilos de diseño. Si codifica para una base de datos relacional y luego decide cambiar a un valor de clave turbia, necesitará reescribir completamente la mitad de su código.

Si comienza con archivos planos y cambia a una base de datos relacional, probablemente terminará tirando la mitad de su código ya que sus desarrolladores habrán perdido el tiempo implementando una base de datos pobre.

James Anderson
fuente
-1

¿Debería intentar la persistencia en un archivo plano antes de la base de datos?

Sí, deberías probarlo. Especialmente si nunca lo has probado antes. No importa cómo resulte, aprenderás algo.

Alex Chaffee
fuente