Bonjour
comme vous le savez j’ai récemment travaillé sur l’import de data dans dolibarr via les api et je suis en train d’en regarder le résultat
La première chose qui m’a choqué c’est la taille de la table llx_actioncomm et après une rapide analyse j’ai découvert cela :
une dizaine de champs varchar(255) le plus souvent vide, quand on sait que cette table est utilisé un peu partout, c’est un vrai boulet que l’on se traine.
un autre truc me pique les yeux c’est le champs recurid un id varchar, et indexé en plus???
Je propose que l’on « externalise » ces champs dans une autre table qui sera alimenté si on en a besoin
Bonjour
En phase avec ta proposition. D’autant qur les chams en question semblent avoir été ajoutés pournstocker des informations spécifiques aux événements de type email.
+1 pour séparer la chose. Etape 1 faire la PR de changement de structure et voir si elle est mergée .
Cette étape passée il restera du taf… A organiser via un mini Giff ? Prêt à participer (code finance). Mais déjà faire valider le changement de structure…
Note que cette approche est réalisable par le moteur de la bdd lui même, c’est ce qui m’est déjà arrivé de faire sur des gros vieux dolibarr (voir Partitioning Overview - MariaDB Knowledge Base) mais je partage ton point de vue ça serait bon d’améliorer tout ça dès « l’origine du stockage »
tant qu’on est dans les changements sur cette table, j’ai remarqué récemment que si on veut faire un lien vers un évènement en extrafield (actioncomm:comm/action/class/actioncomm.class.php), cela ne fonctionne pas car pas de ‹ rowid › mais un ‹ id › dans la table, possible de le renommer au passage ?
la deuxième ce sera de référencer où sont utilisés ses champs et modifier les pages
enfin ce sera le transfert des anciennes données et la suppression des anciennes colonnes
.
