Design de tables SQL

Bonjour à tous
Mon problème: comment représenter correctement les propriétés suivantes
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)

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
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...

niuxe a écrit :


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

Le viens de relire cette discussion. Je ne vois pas de liens à ce sujet.