Q:

Creating a one to many polymorphic relationship with doctrine

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.

A:

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 and Address:
interface iNotable
{
    public function getNotes();
}

Here's Book as an example:
class Book implements iNotable {
    /**
     * @OneToMany(targetEntity="Note", mappedBy="book")
     **/
    protected $notes;

    // ...        

    public function getNotes()
    {
        return $this->notes;
    }
}

Note then needs @ManyToOne relationships going the other way, only one of which will apply for each entity instance:
class Note {
    /**
     * @ManyToOne(targetEntity="Book", inversedBy="notes")
     * @JoinColumn
     **/
    protected $book;

    /**
     * @ManyToOne(targetEntity="Image", inversedBy="notes")
     * @JoinColumn
     **/
    protected $image;

    /**
     * @ManyToOne(targetEntity="Address", inversedBy="notes")
     * @JoinColumn
     **/
    protected $address;

    // ...
}

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:
/**
 * @PrePersist @PreUpdate
 */
public function validate()
{
    $refCount = is_null($book) ? 0 : 1;
    $refCount += is_null($image) ? 0 : 1;
    $refCount += is_null($address) ? 0 : 1;

    if ($refCount != 1) {
        throw new ValidateException("Note references are not set correctly");
    }
}

A:

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.

