Definir les claus primáries per vincular tasques

Dissenyar una base de dades per a la gestió de tasques no és només crear taules; és construir el teixit que mantindrà la coherència de la teva informació. Una estructura mal definida és una recepta per a dades duplicades o, pitjor, tasques “òrfenes” que ningú sap d’on han sortit.

1. Definició del Model Relacional

Per vincular tasques de manera eficaç, necessitem tres pilars: Usuaris, Projectes i Tasques.

Taula: Usuaris

• PK: id_usuari (INT, Auto-increment): Un identificador numèric únic.
  • Justificació: Utilitzem una clau subrogada (id) en lloc del correu electrònic com a PK perquè els indexs numèrics són més ràpids i els correus poden canviar, cosa que trencaria les relacions si fossin PK.

Taula: Projectes

• PK: id_projecte (INT, Auto-increment): Identificador únic del projecte.
• FK: id_creador (References Usuaris.id_usuari): Qui ha creat el projecte.

Taula: Tasques

• PK: id_tasca (INT, Auto-increment): Identificador únic de la tasca.
• FK: id_projecte (References Projectes.id_projecte): Vincula la tasca a un context.
• FK: id_assignat (References Usuaris.id_usuari): L’usuari responsable de l’execució.
• FK: id_pare (References Tasques.id_tasca, Nullable): Per permetre sub-tasques (relació recursiva).

2. Justificació tècnica: Per què aquestes claus?

Criteri	Descripció
Integritat Referencial	Les FK impedeixen que assignis una tasca a un projecte que no existeix o a un usuari que ha estat esborrat.
Unicitat	Les PK garanteixen que cada tasca sigui una entitat atòmica. Encara que dues tasques es diguin “Revisar pressupost”, el seu ID les diferencia sense error possible.
Funcionalitat Real	La relació FK id_pare dins de la mateixa taula de tasques permet jerarquies infinites, essencial en metodologies com Agile o GTD.

3. Restriccions (Constraints) i Índexs

Perquè el sistema no es degradi amb el temps, hem d’aplicar regles estrictes:

1. Restricció ON DELETE CASCADE: En la FK de id_projecte dins de Tasques. Si s’esborra un projecte, totes les seves tasques han de desaparèixer. No volem dades escombraria.
2. Restricció NOT NULL: Tant id_projecte com el títol de la tasca han de ser obligatoris. Una tasca “al buit” no és operativa.
3. Índexs (Indexes):
   • Crear un índex a Tasques.id_assignat.
   • Crear un índex a Tasques.estat.
   • Per què? Les consultes més habituals seran “Quines tasques tinc jo?” o “Quines tasques estan pendents?”. Sense índexs, la base de dades hauria de llegir tota la taula cada vegada.

4. Casos d’ús

• Vincular tasques a una fita (Milestone): Si afegeixes una taula de Fites, la FK aniria a la taula Tasques. Això permet agrupar tasques cronològicament.
• Traçabilitat de responsabilitat: Gràcies a la FK id_assignat, el sistema pot enviar notificacions automàtiques només a l’usuari implicat quan la tasca canvia d’estat.
• Subtasques: En definir la FK id_pare, pots crear una estructura d’arbre. Una tasca “Preparar esdeveniment” (ID 10) pot tenir subtasques amb id_pare = 10 (Llogar sala, Contractar càtering, etc.).

Aquí teniu la taula de claus primàries per vincular tasques: