Simply put, should interfaces always be used for Class hinting?

I usually have several base classes (User, File, Tags, Tag, etc...) that I use as primary arguments within my program.

PHP Code:
class User {}
class 
UserViews {
public function 
__construct(User $owner); //reads the owners views

But what happens if everytime the User class gets instantiated, it has some complicated query that takes up process? This would mean that the all that information is technically forced to be extracted from the db even if its not going to be used (because this is what a User is, an active record from the database).

Here's a example of when I SHOULD'VE used an interface:

PHP Code:

class BlogArticle {

public function 
__construct($id) {
$id = (int)$id;
$query mysql_query('SELECT name,text,date FROM blogs WHERE id='.$id.' LIMIT 1');

//then all this info gets assigned to the class members
}

}

class 
BlogRating {
    public function 
__construct(BlogArticle $b);
    public function 
setRating($number);

This is basically a rating system for a blog. So imagine, when an AJAX call is made:

PHP Code:
$id = (int)$_GET['b'];
$r = (int)$_GET['r'];
try {
$blog = new Blog($id);
$rating = new BlogRating($blog);
$rating->setRating($r);
}
catch(
Exception $e) {} 
This would mean that EVERYTIME you want to rate something then you need to have a blog article instance (and therefore query and fetch the TEXT from the database), then you can rate (whether you need to use the blog instance anymore or not).

I should've just used an interface called IBlog and then made an AJAX-Blog-Article class that only fetches what I need for the ajax request to do its job.


So my final question is, should interfaces always be used for class hinting? This way, polymorphism is flexible throughout the application. But I'm concerned about the performance hit of having so many interfaces - how well does PHP run with such a complex OO architecture? Should I be worried?