Let me start by outlining the scenario. I have a Note object that can be assigned to many different objects
- A Book can have one or moreNotes.
- An Image can have one or more Notes.
- A Address can have one or more Notes.
What I envision the database to look like:
book
id | title | pages
1 | harry potter | 200
2 | game of thrones | 500
image
id | full | thumb
2 | image.jpg | image-thumb.jpg
address
id | street | city
1 | 123 street | denver
2 | central ave | tampa
note
id | object_id | object_type | content | date
1 | 1 | image | "lovely pic" | 2015-02-10
2 | 1 | image | "red tint" | 2015-02-30
3 | 1 | address | "invalid" | 2015-01-05
4 | 2 | book | "boobies" | 2014-09-06
5 | 1 | book | "prettygood" | 2016-05-05
The question is, how do I model this inside of Doctrine. Everything I have read about talks about single table inheritance without a one to many relationship.
To note (no pun intended ;), you may notice that note never needs unique attributes based on the object its related to.
Ideally I can do $address->getNotes()
which would return the same type of Note object that $image->getNotes()
would return.
At the very minimum the problem I am trying to solve is to avoid having three different tables: image_notes, book_notes and address_notes.
The closest you can get is by using a unidirectional One-To-Many with a join table. In doctrine this is done with a unidirectional Many-To-Many with a unique constraint on the join column.
The disadvantage of this solution is that it is unidirectional meaning that your note is not aware of the owning side of the relationship. But at first glance it looks like this should not be a problem in your case. You will lose the
object_id
andobject_type
column in the note table.In full code this would look like this:
A
NotesTrait
with setters and getters for notes to prevent code duplication:Your
Book
entity:Your
Address
entity:Your
Image
entity:Personally I wouldn't use a superclass here. Think there's more of a case for an interface that would be implemented by
Book
,Image
andAddress
:Here's Book as an example:
Note
then needs@ManyToOne
relationships going the other way, only one of which will apply for each entity instance:If you don't like the multiple references to each notable class here you could use inheritance and have something like an
AbstractNotable
superclass using single table inheritance. Although this might seem tidier now, the reason I wouldn't recommend it is as your data model grows you may need to introduce similar patterns that could eventually make the inheritance tree become unmanageable.EDIT: It would also be useful to have
Note
validator to ensure data integrity by checking that exactly one of$book
,$image
or$address
is set for each instance. Something like this:This question introduces unneccessary complexity into the application. Just because the notes have the same structure does not mean that they are the same entity. When modelling the database in 3NF, they are not the same entity because a note can not be moved from a Book to an Address. In your description there is a definitive parent-child relation between book and book_note, etc so model it as such.
More tables is not a problem for the database but unneccessary code complexity is, as this question demonstrates. It is just being clever for clevers sake. This is the trouble with ORMs, people stop doing full normalization and don't model the database correctly.
As you cant have several foreign keys on one column, you have 2 solutuons:
one2many
relations between Book/Image/Address and Note, so it would create a join table for each relation like book_note, image_note etc. holding the id pairs book.id-note.id etc. (I mean one2many instead of many2many because there usually is no point for a note to know which book or image or address it belongs to)http://doctrine-orm.readthedocs.org/projects/doctrine-orm/en/latest/reference/association-mapping.html#one-to-many-unidirectional-with-join-table
or make multiple entities
BookNote
,ImageNote
,AddressNote
related to a book/image/address and a note and other data if for example one type of a note has some other data in it.you can use single table inheritance as described in accepted answer to this question, but it is a solution similar to one proposed by Steven, which makes you hold additional data in the discriminator column.
Multiple JoinColumns in Symfony2 using Doctrine annotations?
Doctrine documentation also mentions a performance hit in certain situations.
http://doctrine-orm.readthedocs.org/projects/doctrine-orm/en/latest/reference/inheritance-mapping.html#performance-impact
Solution given by Steve Chambers solves a problem but you force the note table to hold unnecessary data(empty id columns for other objects)
I add another answer after reading your question once more and realizing that you stated "I want to avoid adding another join table".
Make a
Note
base entity and extend this class in 3 different note entities for example:BookNote
,AddressNote
andImageNote
. In my solution the note table would look like this:You cannot use one common column
object_id
because of the foreign key constraints.A
NotesTrait
with setters and getters for notes to prevent code duplication:Your
Note
entity:Your
BookNote
entity:Your
AddressNote
entity:Your
ImageNote
entity:Your
Book
entity:Your
Address
entity:Your
Image
entity: