Est-il correct d'utiliser des associations "sémantiquement inversées", comme Message blongsTo Attachment, dans CakePHP?

Question

Supposons que nous avons le diagramme ER partiel suivant:

Notez que la table attachments sera ensuite utilisé pour les messages', soumissions, missions et des conférences de attachements.

Le problème est avec les 3 one-to-one relations entre attachments et messages, submissions et assignments. Selon les conventions de CakePHP, Message belongsTo Attachment (et Attachment hasOne Message) car Message contient la clé étrangère (la même chose s'applique aux 2 autres relations). Bien sûr, il est plus logique de dire que Message hasOne Attachment (et que Attachment belongsTo Message). Si nous avions seulement messages et attachments, il serait facile de "orienter correctement" la relation en déplaçant la clé étrangère à attachments.

Mais le problème est à nouveau que messages, submissions, assignments et lectures ont des relations avec la même table attachments. Une façon d'obtenir les relations "sémantiquement correct" est d'avoir 4 modèles différents: MessageAttachment, SubmissionAttachment, AssignmentAttachment et LectureAttachment.

En supposant que nous ne sommes intéressés à récupérer la pièce jointe d'un certain message, la soumission, ou la cession, est-il correct d'utiliser ces sémantiquement renversées associations, ou devrions-nous orienter correctement les en séparant Attachment en 4 différents modèles comme mentionné ci-dessus?

Answer 1

Par sémantique, vous entendez également la sémantique naturelle du langage. Mais vous parlez d'un scénario technique particulier qui contient une sémantique différente.

C'est parfaitement bien. Ce ne sont que des noms. Si vous avez A et B (pièces jointes et messages), et dans votre cas B hasOne A, alors il est la bonne chose à dire pièce jointe hasOne un message.

Answer 2

Attention: cette réponse va un peu dans le sens de "vous devriez pouvoir le faire avec un framework MVC". Je ne suis pas familier avec CakePHP, et en regardant brièvement la documentation je ne peux pas comprendre comment faire ce qui suit.

En Perl DBIx :: Class (que je connais bien), il est possible d'imposer des contraintes supplémentaires dans les relations belongs to au lieu de simplement fk matching. Je résoudre ce problème en ajoutant un champ type à attachment, qui indique le type d'objet (par exemple, message, lecture) qui possède ce attachment particulier, puis donner un attachmentforeign_id.

La syntaxe de la requête serait SELECT * from attachment WHERE foreign_id == myId AND type == MyType.

Il semble que cette structure vous permettrait d'éliminer la table attachments_lectures, car cela semble vous permettre d'avoir beaucoup de pièces jointes par cours.Vous obtiendrez également gratuitement d'être en mesure d'avoir de nombreuses pièces jointes pour les affectations, les soumissions et les messages si vous étiez si incliné.