Entre développeurs
Abstraction des données

Hello,

Partant du principe que Robert à été développé selon un besoin spécifique d'une association Acousmie mais que les problèmes qu'il résout sont extensible à pas mal de structures (gestion de personnel, gestion de calendrier, gestion de stock...), je pense qu'il serait bon de réfléchir à une interface de données qui soit entièrement paramétrable. Le point soulevé par pas mal d'utilisateurs est souvent les catégories codée en dur. Bien entendu cela est une amélioration déjà prévu pour cette nouvelle version.
Si on pousse plus loin ce résonnement et à la vue des données nécessaires qui diffèrent pour plusieurs structures pour un item ( pour les 'gens' par exemple dans le monde du spectacle il y a le numéro GUSO qui ne s'appliquerait pas à une entreprise dans un autre secteur ), quelle serait les possibilités pour que chaque administrateur du Robert 2 puisse adapter les champs de données à son utilisation ?

Dans le thread sur la création d'un système de scan de codes barres, @alexishermel nous donne pas mal de paramètres qui ne me seraient pas venu à l'idée. Aussi je pensais à une structure de donnée de type arborescence.

Pour chaque item on peut créer des enfant de niveau 1

  • materiel/id
  • materiel/nom_long

et/ou imbriquer des niveaux

  • materiel/proprietaire/contact
  • materiel/proprietaire/photo

Tout en spécifiant le type de data dans chaque champ créé.

Cette classe/objet de base serait un socle puissant qui, je pense, pourrait soutenir les données de chaque 'sections'
matériel/
matériel/son/micros
matériel/lumière/spot
utilisateurs/
événements/
bénéficiaires/

Voire d'en créer d'autres pour adapter rapidement Robert à d'autres problématiques...

Qu'en pensez vous ?

Hello, Partant du principe que Robert à été développé selon un besoin spécifique d'une association Acousmie mais que les problèmes qu'il résout sont extensible à pas mal de structures (gestion de personnel, gestion de calendrier, gestion de stock...), je pense qu'il serait bon de réfléchir à une interface de données qui soit entièrement paramétrable. Le point soulevé par pas mal d'utilisateurs est souvent les catégories codée en dur. Bien entendu cela est une amélioration déjà prévu pour cette nouvelle version. Si on pousse plus loin ce résonnement et à la vue des données nécessaires qui diffèrent pour plusieurs structures pour un item ( pour les 'gens' par exemple dans le monde du spectacle il y a le numéro GUSO qui ne s'appliquerait pas à une entreprise dans un autre secteur ), quelle serait les possibilités pour que chaque administrateur du Robert 2 puisse adapter les champs de données à son utilisation ? Dans le thread sur la création d'un système de scan de codes barres, @alexishermel nous donne pas mal de paramètres qui ne me seraient pas venu à l'idée. Aussi je pensais à une structure de donnée de type arborescence. Pour chaque item on peut créer des enfant de niveau 1 - materiel/id - materiel/nom_long et/ou imbriquer des niveaux - materiel/proprietaire/contact - materiel/proprietaire/photo Tout en spécifiant le type de data dans chaque champ créé. Cette classe/objet de base serait un socle puissant qui, je pense, pourrait soutenir les données de chaque 'sections' matériel/ matériel/son/micros matériel/lumière/spot utilisateurs/ événements/ bénéficiaires/ Voire d'en créer d'autres pour adapter rapidement Robert à d'autres problématiques... Qu'en pensez vous ?
edited Apr 11 '16 at 3:55 pm

Je pense qu'il est intéressant d'abstraire certaines données pour rendre Robert utilisable dans d'autres situations que la gestion son/lumière. Cependant il faut aussi se fixer des limites à l'abstraction, sinon ça va donner un logiciel soit trop compliqué à développer, soit trop trop compliqué à utiliser (trop de paramétrage, etc.), soit trop générique pour être vraiment utile (il faut aussi intégrer intelligemment tous ces champs dans l'interface).

Si on arrive à une structure générique, on peut aussi fournir différentes "distributions" du logiciel, avec des catégories/champs/etc. déjà préconfigurés pour un domaine précis (son/lumière, matos info, gestion de personnel, bibliothèque, etc.). Ce serait le même code source, mais juste avec un fichier de paramétrage différent appliqué à l'installation pour ajouter les données spécifiques.

Au niveau des champs personnalisables pour chaque item, je ne pense pas qu'il faille faire des sous-niveaux. En général, s'il y a des sous-niveaux (comme dans ton exemple d'ailleurs) c'est parce qu'en fait ça concerne un item différent (ici le propriétaire). Donc il vaut mieux garder les champs sur l'autre item et permettre de faire le lien entre les 2. Là ça donnerait :

  • materiel/id
  • materiel/nom_long
  • materiel/id_proprietaire

et :

  • proprietaire/id
  • proprietaire/contact
  • proprietaire/photo

(L'id du propriétaire peut être caché de l'utilisateur)
En plus, sinon on se retrouve avec plein d'infos dupliquées ce qui n'est pas terrible (là les infos du propriétaire se retrouvent dupliquées sur chaque matériel). C'est pas uniquement une histoire de place mémoire, mais aussi si tu dois mettre à jour les infos du propriétaire, t'es obligé de modifier à la main chacun de son matos...

Les sous-niveaux seraient plutôt utiles pour les catégories par exemple. Outre la modification des catégories principales son/lumière/structure/transport, l'intérêt serait de pouvoir créer des sous-catégories : par exemple dans micros, séparer entre HF et filaires (puis entre chant ou instru, etc.)
Il pourrait aussi y avoir des catégories pour autre chose que le matériel, et y avoir des champs spécifiques aux items d'une catégorie.
Par exemple on peut avoir une table enregistrant les personnes, mais dedans mettre en place des catégories utilisateur/propriétaire/bénéficiaire/technicien/etc. où il y aurait peut-être des champs spécifiques à une catégorie.
On peut aussi avoir une table lieu, qui se séparerait entre lieux d'événement, clients, lieux de stockage, etc.
Idem pour les événements, je suis sûr qu'il peut y avoir une utilité à utiliser des catégories...

Bon, après il faut voir comment le mettre en place techniquement parce que c'est pas trivial à mon avis smile

Enfin voilà ce que j'en pense, mais c'est juste mon point de vue smile

Je pense qu'il est intéressant d'abstraire certaines données pour rendre Robert utilisable dans d'autres situations que la gestion son/lumière. Cependant il faut aussi se fixer des limites à l'abstraction, sinon ça va donner un logiciel soit trop compliqué à développer, soit trop trop compliqué à utiliser (trop de paramétrage, etc.), soit trop générique pour être vraiment utile (il faut aussi intégrer intelligemment tous ces champs dans l'interface). Si on arrive à une structure générique, on peut aussi fournir différentes "distributions" du logiciel, avec des catégories/champs/etc. déjà préconfigurés pour un domaine précis (son/lumière, matos info, gestion de personnel, bibliothèque, etc.). Ce serait le même code source, mais juste avec un fichier de paramétrage différent appliqué à l'installation pour ajouter les données spécifiques. Au niveau des champs personnalisables pour chaque item, je ne pense pas qu'il faille faire des sous-niveaux. En général, s'il y a des sous-niveaux (comme dans ton exemple d'ailleurs) c'est parce qu'en fait ça concerne un item différent (ici le propriétaire). Donc il vaut mieux garder les champs sur l'autre item et permettre de faire le lien entre les 2. Là ça donnerait : - materiel/id - materiel/nom_long - materiel/id_proprietaire et : - proprietaire/id - proprietaire/contact - proprietaire/photo (L'id du propriétaire peut être caché de l'utilisateur) En plus, sinon on se retrouve avec plein d'infos dupliquées ce qui n'est pas terrible (là les infos du propriétaire se retrouvent dupliquées sur chaque matériel). C'est pas uniquement une histoire de place mémoire, mais aussi si tu dois mettre à jour les infos du propriétaire, t'es obligé de modifier à la main chacun de son matos... Les sous-niveaux seraient plutôt utiles pour les catégories par exemple. Outre la modification des catégories principales son/lumière/structure/transport, l'intérêt serait de pouvoir créer des sous-catégories : par exemple dans micros, séparer entre HF et filaires (puis entre chant ou instru, etc.) Il pourrait aussi y avoir des catégories pour autre chose que le matériel, et y avoir des champs spécifiques aux items d'une catégorie. Par exemple on peut avoir une table enregistrant les personnes, mais dedans mettre en place des catégories utilisateur/propriétaire/bénéficiaire/technicien/etc. où il y aurait peut-être des champs spécifiques à une catégorie. On peut aussi avoir une table lieu, qui se séparerait entre lieux d'événement, clients, lieux de stockage, etc. Idem pour les événements, je suis sûr qu'il peut y avoir une utilité à utiliser des catégories... Bon, après il faut voir comment le mettre en place techniquement parce que c'est pas trivial à mon avis (:| Enfin voilà ce que j'en pense, mais c'est juste mon point de vue :)
edited Apr 11 '16 at 3:56 pm

Héhé, c'est là qu'interviennent les jointures, et le micro framework PHP qu'on a développé avec @Moutew à la base, et que j'ai amélioré au fil du temps, à savoir : PDO-Altitude ! C'est hyper simple mais ultra pratique pour utiliser des bases de données MySQL ou SQLite en un tour de main, et cerise sur le gâteau, ça gère les (pseudo) jointures automatiquement. Je dis "pseudo" car Altitude n'utilise pas les jointures "natives" de MySQL, car tout les moteurs ne sont pas compatibles, et SQLite non plus, du coup on utilise une astuce pour faire des jointures (cf. la documentation de Altitude).

Du coup je parle de jointures parce que c'est exactement ce dont parle @fbastien, faire le lien entre plusieurs entités dans la base, sans qu'il n'y ait de redondance d'infos, grâce aux ID des entrées dans les tables. Et du coup, plus besoin non plus de faire des niveaux fixés, il suffit de créer des colonnes de jointures dans les tables pour les lier. Par ex: ("FK_" pour préfixer la colonne en "Foreign Key" )

  • table "matos"
    • ID
    • ref
    • FK_proprio_ID
    • ...
  • table "proprios"
    • ID
    • Nom_boite
    • FK_user_ID
    • ...
  • table "users"
    • ID
    • email
    • nom
    • ...

Comme ça, avec Altitude (une fois configuré) il suffit de faire une requête sur un matos pour avoir toutes les infos d'un coup ! Genre tu demandes le matos #3 et tu retrouves les infos suivantes :

  • ID => 3
  • ref => "blabla"
  • proprio => {
    • ID=>42,
    • Nom_boite=>"sushi",
    • user=>{
      • ID =>12
      • email => "email@example.net"
      • nom => "SushiMan"
    • ... }
  • ... }

Et du coup le simple fait de lier un ID d'une table vers une autre crée le niveau.

En ce qui concerne la catégorisation des choses, je pense qu'on pourrait essayer de penser plutôt à un système de TAGS.
Par exemple, avoir une liste de mots éditable, qui soit utilisée par chaque table (entité) "taggable" dans la base. Par exemple, les utilisateurs ne seraient pas "taggables", alors que le matos oui ; ce qui permettrai de catégoriser le matériel facilement, tout en gardant la possiblité de le mettre dans plusieurs "categories" à la fois (par ex. possibilité de mettre les deux tags "son" et "lumière" sur une barquette 220V par exemple)
Après, on peut aussi imaginer différentes catégories de tags (tags matos, tags clients...) smile

Bien sûr tout cela est faisable, et même pas très compliqué à coder (merci Altitude encore une fois lol).

Enfin, concernant "l'abstraction" des choses disponibles dans le Robert, entièrement d'accord avec vous, cependant je pense qu'on peut effectivement taper large, sans tomber non plus dans le trop générique. Fixer les limites va être ardu...

Sinon, une idée comme ça, utiliser des termes très génériques qui correspondent à chaque partie fondamentale du Robert, c'est à dire le coeur du système, pour ensuite proposer à l'installation de faire correspondre ses propres mots, vocabulaire à ces termes génériques. Par ex :

  • Service lui-même (les "plans" dans Robert 1)
  • Objets utilisés pour le service (le matériel)
  • Personnes fournissant le service (les techniciens)
  • Planning des services (calendrier)
  • Bénéficiaires du service (clients)
  • ...

C'est pas très compliqué à mettre en place, je l'ai déjà fait dans le SaAM smile

Voili voilou, my "2 cents" on this topic smile
Cheers !

Héhé, c'est là qu'interviennent les jointures, et le micro framework PHP qu'on a développé avec @Moutew à la base, et que j'ai amélioré au fil du temps, à savoir : [PDO-Altitude](http://altitude.polosson.com/) ! C'est hyper simple mais ultra pratique pour utiliser des bases de données MySQL ou SQLite en un tour de main, et cerise sur le gâteau, ça gère les (pseudo) jointures automatiquement. Je dis "pseudo" car Altitude n'utilise pas les jointures "natives" de MySQL, car tout les moteurs ne sont pas compatibles, et SQLite non plus, du coup on utilise une astuce pour faire des jointures (cf. la documentation de Altitude). Du coup je parle de jointures parce que c'est exactement ce dont parle @fbastien, faire le lien entre plusieurs entités dans la base, sans qu'il n'y ait de redondance d'infos, grâce aux ID des entrées dans les tables. Et du coup, plus besoin non plus de faire des niveaux fixés, il suffit de créer des colonnes de jointures dans les tables pour les lier. Par ex: ("FK_" pour préfixer la colonne en "Foreign Key" ) - table "matos" - ID - ref - **FK_proprio_ID** - ... - table "proprios" - ID - Nom_boite - **FK_user_ID** - ... - table "users" - ID - email - nom - ... Comme ça, avec Altitude (une fois configuré) il suffit de faire une requête sur un matos pour avoir toutes les infos d'un coup ! Genre tu demandes le matos #3 et tu retrouves les infos suivantes : - ID => 3 - ref => "blabla" - **proprio** => { - ID=>42, - Nom_boite=>"sushi", - **user**=>{ - ID =>12 - email => "email@example.net" - nom => "SushiMan" - ... } - ... } Et du coup le simple fait de lier un ID d'une table vers une autre crée le niveau. En ce qui concerne la **catégorisation des choses**, je pense qu'on pourrait essayer de penser plutôt à un système de **TAGS**. Par exemple, avoir une liste de mots éditable, qui soit utilisée par chaque table (entité) "taggable" dans la base. Par exemple, les utilisateurs ne seraient pas "taggables", alors que le matos oui ; ce qui permettrai de catégoriser le matériel facilement, tout en gardant la possiblité de le mettre dans plusieurs "categories" à la fois (par ex. possibilité de mettre les deux tags "son" et "lumière" sur une barquette 220V par exemple) Après, on peut aussi imaginer différentes catégories de tags (tags matos, tags clients...) :P Bien sûr tout cela est faisable, et même pas très compliqué à coder (merci Altitude encore une fois lol). Enfin, concernant "l'abstraction" des choses disponibles dans le Robert, entièrement d'accord avec vous, cependant je pense qu'on peut effectivement taper large, sans tomber non plus dans le trop générique. Fixer les limites va être ardu... Sinon, une idée comme ça, utiliser des termes très génériques qui correspondent à chaque partie fondamentale du Robert, c'est à dire le coeur du système, pour ensuite proposer à l'installation de faire correspondre ses propres mots, vocabulaire à ces termes génériques. Par ex : - Service lui-même (les "plans" dans Robert 1) - Objets utilisés pour le service (le matériel) - Personnes fournissant le service (les techniciens) - Planning des services (calendrier) - Bénéficiaires du service (clients) - ... C'est pas très compliqué à mettre en place, je l'ai déjà fait dans le SaAM ;) Voili voilou, my "2 cents" on this topic :) Cheers !
edited Apr 11 '16 at 3:56 pm

Effectivement, en termes plus techniques, c'est bien de jointure que je parlais, mais comme je ne connais pas les connaissance de Moutew, j'ai essayé d'expliquer en termes "normaux" smile

Je suis d'accord avec toi par rapport au fait qu'il vaut mieux des tags plutôt que de limiter à une seule (sous-)catégorie. Par contre je pense qu'il faudrait garder la possibilité de faire des sous-niveaux dans les tags.

Pour la personnalisation, on peut proposer plusieurs choix à l'installation : soit l'utilisateur saisis effectivement tout le vocabulaire etc., soit il pourrait choisir parmi l'une des configurations déjà pré-configurées. L'idéal serait même de pouvoir importer/exporter cette configuration sous forme de fichier XML ou autre, comme ça non seulement à l'installation on peut importer les configurations courantes qu'on propose, mais on permettrait aussi aux utilisateurs de partager ou migrer leurs propres configurations.

Je t'avoue que j'ai pas pris le temps de regarder votre framework, il faut que je le fasse un de ces quatre... smile

Effectivement, en termes plus techniques, c'est bien de jointure que je parlais, mais comme je ne connais pas les connaissance de Moutew, j'ai essayé d'expliquer en termes "normaux" :) Je suis d'accord avec toi par rapport au fait qu'il vaut mieux des tags plutôt que de limiter à une seule (sous-)catégorie. Par contre je pense qu'il faudrait garder la possibilité de faire des sous-niveaux dans les tags. Pour la personnalisation, on peut proposer plusieurs choix à l'installation : soit l'utilisateur saisis effectivement tout le vocabulaire etc., soit il pourrait choisir parmi l'une des configurations déjà pré-configurées. L'idéal serait même de pouvoir importer/exporter cette configuration sous forme de fichier XML ou autre, comme ça non seulement à l'installation on peut importer les configurations courantes qu'on propose, mais on permettrait aussi aux utilisateurs de partager ou migrer leurs propres configurations. Je t'avoue que j'ai pas pris le temps de regarder votre framework, il faut que je le fasse un de ces quatre... :P
edited Apr 11 '16 at 3:56 pm

@fbastien : je hais les base de données ! c'est peut être de là que viens PDO-Altitude smile

Le système de Tags : très chouette idée ! facile à ranger dans une organisation hiérarchique.

La personnalisation du vocabulaire avec des fichiers de config c'est très bon ! Vraiment dans l'esprit Open Source en plus.

Je vais me creuser un peu plus la tête sur une proposition de limite à l'abstraction pour amorcer le débat.

@fbastien : je hais les base de données ! c'est peut être de là que viens PDO-Altitude ;) **Le système de Tags** : très chouette idée ! facile à ranger dans une organisation hiérarchique. La personnalisation du vocabulaire avec des fichiers de config c'est très bon ! Vraiment dans l'esprit Open Source en plus. Je vais me creuser un peu plus la tête sur une proposition de limite à l'abstraction pour amorcer le débat.
edited Apr 11 '16 at 3:56 pm

Arrfff Moutew, mais c'est pratique les bases de données ! no ? smile

Hihi en tout cas complètement d'accord pour l'histoire des fichiers de config, en XML ou JSON (j'aime bien le json) partageables entre utilisateurs, très bonne idée ! Et bien sûr qu'il faudra proposer des configs de base pré-remplies, ne serait-ce que pour l'exemple... Et de toute façon comme il faudra en créer quelques unes pour faire des tests, elles seront dispo de toute manière smile

@fbastien est-ce que tu as eu mon mail avec le lien de synchro vers le dossier de travail ? D'ailleurs, je peux partager ce lien en lecture seule, directement sur le forum non ? Comme ça chacun peut jeter un oeil sur l'évolution des choses... Z'en pensez quoi ?

Arrfff Moutew, mais c'est pratique les bases de données ! no ? (wasntme) Hihi en tout cas complètement d'accord pour l'histoire des fichiers de config, en XML ou JSON (j'aime bien le json) partageables entre utilisateurs, très bonne idée ! Et bien sûr qu'il faudra proposer des configs de base pré-remplies, ne serait-ce que pour l'exemple... Et de toute façon comme il faudra en créer quelques unes pour faire des tests, elles seront dispo de toute manière :) @fbastien est-ce que tu as eu mon mail avec le lien de synchro vers le dossier de travail ? D'ailleurs, je peux partager ce lien en lecture seule, directement sur le forum non ? Comme ça chacun peut jeter un oeil sur l'évolution des choses... Z'en pensez quoi ?
edited Apr 11 '16 at 3:57 pm

@Moutew

je hais les base de données ! c'est peut être de là que viens PDO-Altitude smile

Nan ! Les BDD c'est bien ! smile
Difficile de faire sans en même temps... Après c'est sûr qu'il vaut mieux utiliser un framework que tout un tas de fonctions "bas niveau".

@polosson

Hihi en tout cas complètement d'accord pour l'histoire des fichiers de config, en XML ou JSON (j'aime bien le json)

Effectivement ça peut être JSON aussi, il y a pas forcément besoin de sortir l'artillerie lourde XML smile

est-ce que tu as eu mon mail avec le lien de synchro vers le dossier de travail ?

Ouais, j'ai lu ton mail, mais désolé j'ai pas encore eu le temps de te répondre et de regarder pour le dossier de travail...

@Moutew >je hais les base de données ! c'est peut être de là que viens PDO-Altitude ;) Nan ! Les BDD c'est bien ! :P Difficile de faire sans en même temps... Après c'est sûr qu'il vaut mieux utiliser un framework que tout un tas de fonctions "bas niveau". @polosson >Hihi en tout cas complètement d'accord pour l'histoire des fichiers de config, en XML ou JSON (j'aime bien le json) Effectivement ça peut être JSON aussi, il y a pas forcément besoin de sortir l'artillerie lourde XML :) >est-ce que tu as eu mon mail avec le lien de synchro vers le dossier de travail ? Ouais, j'ai lu ton mail, mais désolé j'ai pas encore eu le temps de te répondre et de regarder pour le dossier de travail...
edited Apr 11 '16 at 3:57 pm
127
6
2
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft