Todo List multi niveaux avec récursivité

Bonjour,

Je suis sur un projet de Todo List, mais ce projet ne comporterait pas que des tâches.
Je voudrais pouvoir ajouter des listes de tâches et peut-être des projets contenant des listes de tâches.
Donc ce projet de Todo List, serait sur deux voir trois niveaux.

Contrainte pour ce projet, l'objet tâche est utilisé aussi bien pour créer un tâche, une liste ou un projet.
Donc je n'ai qu'une seul table dans ma DB, c'est un système récursif.
Technologie utilisée: MySQL, PHP, jQuery, ajax.

Pour le premier niveau, je n'ai pas de problème.
ça se complique pour le deuxième niveau, visuellement, j'imagine des cards de tâches, style Trello, et je voudrai pouvoir ajouter d'autre cards.

Quelqu'un aurait-il des conseils ou exemples à donner?
J'en ai trouvé énormément, mais tous avec des Todo List à un seul niveau.

Voici la structure de ma table SQL:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

CREATE TABLE `task` ( `id` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL, `title` varchar(100) NOT NULL, `description` varchar(255) DEFAULT NULL, `importance` varchar(10) DEFAULT NULL, `due_date` date DEFAULT NULL, `start_date` date NOT NULL, `parent` int(20) NOT NULL, `children` int(20) NOT NULL, `status` enum('à faire','en cours','achevée','un jour peut-être') DEFAULT NULL, `creator` varchar(30) DEFAULT NULL, `category` varchar(50) DEFAULT NULL, `prerequisite` int(5) DEFAULT NULL, `created_at` date NOT NULL, `updated_at` date DEFAULT NULL, `end_date` date DEFAULT NULL, `estimated_time` time DEFAULT NULL, `display_order` int(5) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

---

à quoi correspond le champ "children" ?
si j'ai bien compris, la tache doit avoir un champ qui contient l'identifiant de la tâche parente mais pas de champ pour les tâches enfants.

Bonjour,
il existe un Forum MySQL, qui serait peut-être mieux indiqué, dis nous le si tu veux que l'on déplace ta discussion.

Citation:

---

Envoyé par mathieu

à quoi correspond le champ "children" ?
si j'ai bien compris, la tache doit avoir un champ qui contient l'identifiant de la tâche parente mais pas de champ pour les tâches enfants.

---

J'ai ajouté ce champ là hier, peut-être utilse pour un troisième niveau.
Je m'en tiens au deuxième niveau pour l'instant, une liste aura un numéro (id) et les tâches de cette liste auront toutes le numéro d'id de la liste comme parent.

Citation:

---

Envoyé par NoSmoking

Bonjour,
il existe un Forum MySQL, qui serait peut-être mieux indiqué, dis nous le si tu veux que l'on déplace ta discussion.

---

La conversation va évoluée plus vers du web, certainement avec des partie de code jQuery et ajax. Je dois dire que je ne savais pas trop où la postée.

Citation:

---

La conversation va évoluée plus vers du web

---

Je n'en doute pas mais il est important, sur le forum, de bien scinder tes préoccupations pour ne pas noyer les discussions.

Dans un premier temps il est effectivement important que tu « blindes » tes données et ma proposition était surtout dans ce sens.

Il me semble qu'il existe un proverbe qui dit « chaque chose a son taon et les vaches seront bien gardées », ou quelque chose d'approchant :mrgreen:

lol vous pouvez déplacer la discussion.

Bonjour,

La description du besoin est très succincte, il faut décrire ce qu'est un parent, un enfant, combien une tâche peut avoir de parents (mini, maxi) et d'enfants(mini-maxi)

Décrivez aussi ce que c'est qu'une catégorie, mais c'est très probablement un domaine de valeur à externaliser
Même question concernant les projets, c'est une liste de tâches ok, mais quoi d'autre à leurs sujets ?
Pareil pour les niveaux, décrivez de quoi il s'agit, comment ça fonctionne
Pour tout ça, n'hésitez pas à fournir des exemples concrets.

Le sujet devrait en effet être déplacé, mais non pas dans le forum MySQL, mais plutôt dans le forum lié à la modélisation des bases de données :

• tout vouloir mettre dans une seule table est une hérésie
• le typage des données est incohérent, à commencer par la clef primaire de type varchar :aie:
• la notion de parent / enfant doit très probablement faire l'objet d'une relation reflexive et donc, au niveau tabulaire, d'une table de liens

Bref, vous mettez la charrue avant les boeufs en parlant de tables, de choix de SGBD ou de langage, alors que les fondations sont absentes. C'est le meilleur moyen d'aboutir à une solution inadaptée, peu fiable et peu performante.
Commencez par la base : les règles de gestion et le modèle de données qui en découle ;)

Salut cisman.

Citation:

---

Envoyé par Cisman

Je suis sur un projet de Todo List mais ce projet ne comporterait pas que des tâches.
Je voudrais pouvoir ajouter des listes de tâches et peut-être des projets contenant des listes de tâches.
Donc ce projet de Todo List, serait sur deux voir trois niveaux.

---

C'est peut-être clair pour vous, mais comme on découvre votre sujet, nous ne sommes pas sensés savoir de quoi vous parlez.
Ni sur quoi vous travaillez et encore moins les contraintes que vous devez appliquer pour résoudre vos problèmes.

Citation:

---

Envoyé par Cisman

L'objet tâche est utilisé aussi bien pour créer un tâche, une liste ou un projet.
Donc je n'ai qu'une seul table dans ma DB, c'est un système récursif.

---

Listes, tâches, projets, une seule table et des accès en récursivité.

Citation:

---

Envoyé par Cisman

ça se complique pour le deuxième niveau, visuellement, j'imagine des cards de tâches, style Trello, et je voudrai pouvoir ajouter d'autre cards.

---

Je ne connais pas.

Si je comprends bien, vous avez une structure arborescence.
Chaque noeud de l'arbre sera soit :
--> un projet qui va contenir des listes.
--> une liste qui va contenir des tâches.
--> et le noeud terminal, la tâche.
On retrouve bien vos trois niveaux.

D'un point de vue modélisation, le mieux aurait été de créer trois classes d'entités, de nom "projet", "list" et "tâche".
Liste va pointer sur projet en utilisant une clef étrangère.
Tâche va pointer sur liste, en utilisant une clef étrangère.
Normalement, c'est ainsi que l'on modélise ce qu vous demandez.

Puisque vous désirez tout mettre dans une seule table (franchement je ne comprends pas trop l'intérêt de procéder ainsi), il faut créer un chaînage.
On ne nomme pas cela une récursivité mais un chaînage.
Et le chaînage se fera avec des pointeurs qui seront les adresses de vos lignes.
Et pour se faire, vous devrez utiliser un identifiant technique auto incrémenté afin de rendre chaque ligne unique.

Schématiquement, cela donner ce genre de résultat :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

+---------+------+--------------+ | Adresse | Lien | Désignation | +---------+------+--------------+ | 001 | NIL | projet 1 | +---------+------+--------------+ | 002 | 001 | liste 1-1 | | 003 | 002 | tâche 1-1-1 | | 004 | 002 | tâche 1-1-2 | | 005 | 002 | tâche 1-1-3 | | 006 | 002 | tâche 1-1-4 | +---------+------+--------------+ | 007 | 001 | liste 1-2 | | 008 | 007 | tâche 1-2-1 | | 009 | 007 | tâche 1-2-2 | +---------+------+--------------+ | 010 | 001 | liste 1-3 | | 011 | 010 | tâche 1-3-1 | | 012 | 010 | tâche 1-3-2 | | 013 | 010 | tâche 1-3-3 | +=========+======+==============+ | 014 | NIL | projet 2 | +---------+------+--------------+ | 015 | 014 | liste 2-1 | | 016 | 015 | tâche 2-1-1 | | 017 | 015 | tâche 1-1-2 | +---------+------+--------------+ | 018 | 014 | liste 2-2 | | 019 | 018 | tâche 2-2-1 | | 020 | 018 | tâche 1-2-2 | | 021 | 018 | tâche 1-2-3 | | 022 | 018 | tâche 1-2-4 | +=========+======+==============+ | 023 | NIL | projet 3 | +---------+------+--------------+ | 024 | 023 | liste 3-1 | | 025 | 024 | tâche 3-1-1 | | 026 | 024 | tâche 3-1-2 | | 027 | 024 | tâche 3-1-3 | +---------+------+--------------+ | 028 | 023 | liste 3-2 | | 029 | 028 | tâche 3-2-1 | | 030 | 029 | tâche 1-2-2 | +---------+------+--------------+

---

Dans la colonne lien, NIL signifie que le chaînage se termine là.
Sinon, la valeur correspond à l'adresse de la ligne que vous devez pointer.

Par exemple, "liste 2-1" va pointer sur "projet 2". Cela se fait avec la valeur 014.
Pour bien comprendre, le pointage se fera toujours en remontant dans la table.
Pourquoi ? Parce que la ligne qui sera pointée devra exister au prealable.

@+

Ce que je vous ai communiqué est un exemple de chaînage selon votre demande.
Mais cela ne correspond pas à la réalité de vos besoins car vous êtes partie dans l'idée de faire à l'identique de "Trello".
Que ce soit par Excel, un fichier plat ou quoi que ce soit d'autre, une base de données repose sur des relations.
Vous ne pouvez pas faire à l'identique de ce que vous connaissez car vous aurez de grave problème concernant la fiabilité de vos données.

Comme dit Escartefigue, ne mettez pas la charrue avant les bœufs.

Vous devez commencez pas définir la modélisation de votre base de données.
Pour ce faire, décrire vos règles de gestions, le dictionnaire de données.
A l'issu de cela, commencez par faire une ébauche du modèle entité-relationnel.
Voire si en appliquant les formes normales, vous n'enfreignez pas quelques règles.
Vérifiez que ce modèle correspond à vos besoins.
Prenez un exemple concret et voyez si le modèle vous donne la solution.

Passez ensuite au modèle logique en créant vos tables avec un jeu d'essai complet.
Puis enfin travaillez vos requêtes pour ce que vous cherchez à faire :
--> extraction des données
--> création, mise-à-jour, suppression
--> test de performance

@ Escartefigue : on va essayer de ne pas, encore une fois, renvoyer le sujet dans un autre forum.
La modélisation est facile à faire et ne nécessite pas de grosse difficulté à sa mise en oeuvre.

@+

Il existe globalement 3 méthode de modélisation des arborescences qui offrent plus ou moins d'avantages et d'inconvénient :

• adjacence
• par chemin
• par intervalle

Traditionnellement, c'est par adjacence que conduit la modélisation relationnelles. Mais ceci suppose de manipuler des requêtes récursives avec des CTE (WITH...) et se trouve être peu performant.
La méthode par chemin peut être indiquée si votre SGBDR encapsule des techniques spécifiques pour manipuler ce genre de choses
La méthode intervallaire est recommandé pour maintenir d'excellentes performances en recherches, mais dégrade légèrement les mies à jours… On constate cependant que les mises à jour sont peu fréquentes dans les arborescences, mais que par contre les recherches sont très fréquentes. D'où l'intérêt d'utiliser cette méthode.

D'autres précision dans un poste ultérieur !

A +

ADJACENCE, exemple :

Code:

---

1 2 3 4

CREATE TABLE EMPLOYEE (EMP_ID INT PRIMARY KEY, EMP_ID_CHEF INT REFERENCES EMPLOYEE (EMP_ID) ... )

---

• mise à jour : facile;
• lectures : difficiles, nécessite des requêtes récursives;
• Intégrité : respectée par nature (FK).

Par chemin, exemple :

Code:

---

1 2 3 4

CREATE TABLE EMPLOYEE (EMP_ID INT PRIMARY KEY, EMP_IDS_PATH VARCHAR(max) ... )

---

Dans la colonne EMP_IDS_PATH sont concaténés tous les ID des employés par lequel on accède à l'employé visé.

• mise à jour : difficile (redondance);
• lectures : moyenne à difficiles, nécessite quelques requêtes récursives;
• Intégrité : difficile à respecter… nécessite des déclencheurs.

Par intervalle, exemple :

Code:

---

1 2 3 4 5 6

CREATE TABLE EMPLOYEE (EMP_ID INT PRIMARY KEY, EMP_BG INT NOT NULL, EMP_BD INT NOT NULL, EMP_NIVEAU INT NOT NULL, ... )

---

Les bornes droites et gauches "encadrent" les éléments de l'arborescence. Le niveau n'est pas obligatoire, mais facilite les requêtes finales…

• Avantages, extrêmement performant en recherche
• Lent en mise à jour
• Nécessite des déclencheurs pour le pilotage de l'intégrité

Pour le comprendre et l'appliquer, lire les articles que j'ai écrit :
https://sqlpro.developpez.com/cours/arborescence/
https://blog.developpez.com/sqlpro/ptag/arborescence
https://blog.developpez.com/sqlpro/p...vallaire_proce
https://blog.developpez.com/sqlpro/p...edure_de_depla
https://blog.developpez.com/sqlpro/p...edure_de_derec

Améliorations possibles :

• combiner la représentation par adjacence et le mode intervallaire
• Séparer la partie données relationnelles de la partie pilotage de l'arbre en deux tables et faire une vue de synthèse.

A +

Salut SQLPRO.

Dans l'exemple par chemin, la colonne "EMP_IDS_PATH" n'enfreint-elle pas la "Première forme normale" ?
"...dont les attributs possèdent tous une valeur sémantiquement atomique".
Normalement, on ne stocke qu'une valeur par colonne et non une liste de valeur.

P.S.: depuis que le sujet a été déplacé, je pense que nous avons perdu "Cisman".

@+

Citation:

---

Envoyé par mathieu

à quoi correspond le champ "children" ?
si j'ai bien compris, la tache doit avoir un champ qui contient l'identifiant de la tâche parente mais pas de champ pour les tâches enfants.

---

Bonjour,

le champ children, permetrait de définir si c'est une tâche ou une liste.
Si il y a des childrens, c'est que c'est une liste, si pas, c'est une tâche.

Citation:

---

Envoyé par escartefigue

tout vouloir mettre dans une seule table est une hérésie

---

C'est une imposition de mon prof.

Citation:

---

Envoyé par Artemus24

P.S.: depuis que le sujet a été déplacé, je pense que nous avons perdu "Cisman".

---

Je suis toujours bien là, j'ai commencé à coder cette todo list, et j'avais quelques soucis entre PHP, jQuery et ajax.
J'ai commencé à faire la todoList avec un seul niveau pour le moment, donc juste des tâches.

Mais dans un futur proche, elle devrait évoluer vers un deuxième niveau, avec une seul table pour les tâches ou listes, et avec en plus un système multiutilisateur.
Sécuriser la session d'un utilisateur et pouvoir partager des tâches entre utilisateurs.

Salut cisman.

Dans le message #9, j'espère que vous avez compris comment créer plusieurs niveaux par le chaînage des lignes entre elles.

Ainsi la colonne "adresse" correspond à votre clef primaire.
La colonne "lien" va permettre de passer d'un niveau à l'autre.
Les autres colonnes, dont je n'ai spécifié que la colonne désignation, seront à remplir en fonction du niveau où vous vous trouvez.

Dans les explications de SQLPRO, cette façon de faire correspond à "adjacente".

L'inconvénient de cette approche est d'avoir des colonnes non remplies. Pourquoi ?
Vous aurez certainement des colonnes qui sont spécifiques à un seul niveau. Pour les autres niveaux, vous mettrez NULL.
De ce fait, il y a un gaspillage de place.

Donnez un exemple de ce que vous cherchez à faire.

@+

Citation:

---

Envoyé par Artemus24

Salut SQLPRO.

Dans l'exemple par chemin, la colonne "EMP_IDS_PATH" n'enfreint-elle pas la "Première forme normale" ?
"...dont les attributs possèdent tous une valeur sémantiquement atomique".
Normalement, on ne stocke qu'une valeur par colonne et non une liste de valeur.

P.S.: depuis que le sujet a été déplacé, je pense que nous avons perdu "Cisman".

@+

---

Clairement !!!!! C'est pourquoi je ne l'aime pas… Mais s'il est contrôlé automatiquement par les fonctionnalités internes du SGBDR, ça vaut peut être le coup…..

C'est comme les vues indexées, les colonnes calculées, etc...

A +

Salut SQLPRO.

Pour un puriste comme toi, je comprends ton rejet.
Je préfère l'approche adjacente qui m'est plus familière.

@+

Citation:

---

Envoyé par Artemus24

Salut SQLPRO.

Pour un puriste comme toi, je comprends ton rejet.
Je préfère l'approche adjacente qui m'est plus familière.

@+

---

Oui, mais tellement peu performante à cause de l'obligation d'utiliser des requêtes récursives qui ne sont, par nature, pas optimisable.... D’où ma préférence avec la méthode des intervalles (ce qui n’empêche pas l'adjacence...)

A +