Bonjour à tous
Mon problème: comment représenter correctement les propriétés suivantes upload/1593107304-48769-schema.png
Explication:
une personne peut appartenir à un seul pupitre au plus
une personne peut avoir plusieurs rôles (ou aucun)
une personne peut appartenir à plusieurs groupes (ou aucun)

un évènement du calendrier peut concerner tout le monde ou seulement une combinaison fr pupitres, rôles et/ou groupes

Ma question: à votre avis quelle est la méthode la plus appropriée pour représenter ce schéma ?
Ce que je ferais dans un premier jet...

Une table pour :
- les personnes (colonnes id pour pupitres, rôles et groupes)
- les pupitres
- les rôles (colonnes avec caractéristiques de chaque rôles)
- les groupes
- les évènements (date/heure + id adresse)
- les adresses (rue/ville, gps, etc)

Pour les rôles ça peut se discuter de les mettre en database plutôt que dans un fichier de l'appli...
Modifié par Olivier C (25 Jun 2020 - 20:54)
Modérateur
PapyJP a écrit :


Ma question: à votre avis quelle est la méthode la plus appropriée pour représenter ce schéma ?


Et l'eau,

Je passe en coup de vent. Il me semble t'avoir donné de bons liens à ce sujet : Calcul automatique d'un champ en SQL
Modifié par niuxe (25 Jun 2020 - 21:30)
Merci de ta réponse
Pour l’instant à partir du modèle objet de mon appli j’ai fait les choses suivantes
- la table des personnes à un champ "pupitreID", un champ "roleList" qui contient la liste des rôles séparés par des ";" et un champ similaire "groupList"
- la table des évènements a un champ "groupList" similaire dans lequel on trouve en vrac des pupitres, des rôles et des groupes. La correspondance se fait dans l’appli PHP.
Compte tenu de l’utilisation qui en est faite, ce design est raisonnable car il n’est pas nécessaire de faire des requêtes sur ces champs.
J’aimerais bien cependant avoir d’autres avis. Quand on est retraité, l’équivalent de la discussion à la machine à café c’est ce forum.

Comme je l’ai déjà dit, même si j’ai fini ma carrière chez Oracle, je ne suis pas un fanatique du SQL. Cette techno a été inventée avant que les objets soient dans le vent, et c’est la puissance industrielle d’Oracle qui a permis de tuer les bases de données objet. J’ai même constaté en tant qu'employé d’Oracle que les timides avancées mises dans le produit pour y intégrer les objets ont été passées par pertes et profits.
Sur le fond le SQL dérive de recherches faites pour élargir le COBOL dans les années 70, l’approche objet est bien plus tardive et date du milieu des années 80. J’ai constaté que beaucoup de personnes ne comprenaient rien aux objets dans les années 90 et je ne suis pas sûr que ça ait changé beaucoup depuis.
Bon! Je radote comme souvent en fin de journée Smiley vieux Smiley biggrin
Modifié par PapyJP (25 Jun 2020 - 21:37)
PapyJP a écrit :
Quand on est retraité, l’équivalent de la discussion à la machine à café c’est ce forum.

Pour moi aussi qui ne suis pas pro, c'est pourquoi je privilégie ce forum à n'importe quel autres même si je derroge parfois.

Mais alors du coup : qu'est-ce qu'un objet selon ta définition ?
PapyJP a écrit :
J’ai constaté que beaucoup de personnes ne comprenaient rien aux objets dans les années 90 et je ne suis pas sûr que ça ait changé beaucoup depuis.

Je confirme, la notion d'objet n'est pas forcément intuitive.
J'y suis passé dans les années 90 justement et cela ne fut pas forcément un long fleuve tranquille tant cela remettait en cause les fondamentaux que nous avions acquis.
Ceci dit, pour rien au monde je ne reviendrais en arrière vu les bénéfices apportés par ce type de programmation, du moins en général. En PHP par contre, je privilégie les fonctions toutes les fois où c'est possible dans mon générateur de sites web plutôt que des classes, notamment pour des raisons de performance. Instancier un objet et le maintenir en mémoire a un coût et il n'est pas toujours indispensable de passer par la POO pour résoudre un problème donné. C'est un choix à faire au cas par cas, l'avantage de l'objet étant par contre une amélioration de la maintenabilité par découpage des processus plus évident que si on passe par des fonctions. L'encapsulation des données est aussi un plus mais vu que le code est généré via mon outil, la maintenance n'est plus un problème en soi puisque la logique est gérée en amont via des classes Java (là, pour le coup, je pourrais difficilement m'en passer...)
Pour ce qui est de la compréhension "objet" j'ai des collègues bien plus jeunes que moi au boulot qui sont des fans de SQL et n'arrivent que très difficilement à voir de quoi je parle lorsque je leur cause POO, malgré leur niveau intellectuel très largement suffisant. Ce sont deux mondes différents et, a priori, une façon de penser qui semble elle aussi bien différente.
Partant en retraite à la fin du mois de septembre prochain, il leur faut acquérir cette connaissance pour maintenir / faire évoluer la librairie Java que je laisse en héritage et ce n'est pas gagné d'avance, même s'il y aura une documentation ad hoc. Documenter c'est bien, former c'est mieux mais avec le coronamachin nous ne nous voyons plus physiquement depuis la mi mars et ce sera également le cas jusqu'à mon départ. Manque de bol...
Très simplement "penser objet" (quelle que soit le langage et la façon dont on le programme) c’est visualiser un concept (personne, événement) comme un être biologique qui a sa vie propre et a des relations et interactions avec d’autres êtres de même nature (classe), apparentés (héritage) ou très différents. Son comportement (méthodes) agit sur ses propres caractéristiques (propriétés) en relation avec d’autres objets.

A priori on peut penser qu’une table SQL pourrait être une bonne représentation des propriétés d’un objet, et c’est ce que j’essaie de faire, mais ce n’est pas toujours évident, car SQL conduit plutôt à éclater les propriétés dans diverses tables.
Jusqu’à présent j’étais arrivé à éviter d’utiliser des bases de données relationnelles dans les quelques sites que je gère, mais si je veux pouvoir passer la main, il faut se mettre aux standards de fait et éviter les technos personnelles.

Quelques mois après être parti en retraite, on m’a demandé de faire des modifications dans un outil que j’avais fait. A voir comment mes successeurs avaient déjà fait des modifications dans cet outil, je me suis rendu compte que la transmission des savoir faire était une tâche ardue.
L'Ami PapyJP j'espères que nous sommes en phase ??
PDO c'est (PHP Data Objects) ,ainsi l'un des avantage de la programmation Objet, est que lorsque en fin de carrière comme toi ou moi, nous passons le flambeau, si les centaines de pages que nous avons transmises voient des règles changer, le code restera intacte seul l'interface (ici, la DLL de pdo) sera mise à jour c'est bien OK ??
Jean-Pierre-Bruneau a écrit :
L'Ami PapyJP j'espères que nous sommes en phase ??
PDO c'est (PHP Data Objects) ,ainsi l'un des avantage de la programmation Objet, est que lorsque en fin de carrière comme toi ou moi, nous passons le flambeau, si les centaines de pages que nous avons transmises voient des règles changer, le code restera intacte seul l'interface (ici, la DLL de pdo) sera mise à jour c'est bien OK ??

Oui, bien entendu nous sommes en phase.