Diseñando el modelo de datos

Aprovecho que esta clase habla un poco sobre diseño de la aplicación y cambios en la misma para recomendarles un libro que estoy leyendo actualmente que me ha ayudado mucho a mejorar la forma en que escribo código, el libro se llama Practical Object Oriented Design. Este libro incluye ejemplos muy fáciles de enteder pero de alto impacto para el futuro de como diseñamos el implementamos. La autora tiene mucha experiencia con el diseño orientado a objetos y lo mejor es que el libro tiene todos sus ejemplos en Ruby. Espero que todxs le saquen mucho provecho 😄 Chéquenlo aquí

Me ha parecido muy importante y de gran ayuda entender muy bien los modelos de datos (UML) de las aplicaciones que trabajamos en los cursos; yo, personalmente, utilizo el software Visual Paradigm (https://www.visual-paradigm.com/) para una apropiada comprensión de lo que plasmamos en código

Cuando se diseña el modelo de datos de una aplicación, normalmente se hace a través de abstracciones de la realidad, lo que permite comprender mejor el dominio del negocio. Sin embargo, no es recomendable tratar de diseñar toda la estructura exacta si el sistema es muy complejo, porque probablemente haya que hacer muchos cambios en el proceso.

Diseñar utilizando iteraciones es lo mejor para sistemas complejos. Se comienza con algo muy básico y se va mejorando y haciendo más robusto y complejo conforme va avanzando.

En el caso del proyecto para administrar tareas el modelo no es tan complejo por lo que puede diseñarse completamente desde el inicio.

Modelo del proyecto

Task es el modelo principal y agrupa todos los demás modelos.

Las relaciones sería:

• Una categoría puede tener relación con muchas tareas. (Uno a muchos).
• Una tarea puede tener muchos participantes. (Uno a muchos).
• El modelo Participant esta asociado con un usuario, y cada usuario podría ser participante de una tarea. Por lo que una tarea podría tener muchos usuarios, y un usuario podría tener muchas tareas. (Muchos a muchos).
• Una tarea puede tener muchas notas. (Uno a muchos)

Los campos que podría tener cada modelo serían:

• Category: name:string, description:string.
• Task: name:string, description:text, code:string, due-date:string, owner_id:bigint.
• User: email:string, encrypted_password:string
• Participant: role:integer
• Note: body:text

Genial! No entendi bien el porque el participant pero estoy seguro que mas adelante lo entendere mejor. Lo primero que me vino a la mente es que deberia de ser un Task >----< User (Siendo many to many)