I mostly agree with Dime's answer that you want to create your models per business object - the problems that the business is trying to solve should drive how you create the model classes. In practice, I've found that creating one model per table is a good place to start. A properly designed schema is likely to mimic the business processes that you need to model in application code - also called the Domain Model.
Using an Object/Relational Mapping layer is useful so your Domain Model contains the same relationships as the database schema without the need for repetitive calls to a data access layer. Check out Eloquent for PHP as an example. Both the schema and the Domain Model should be designed to support the business processes.
This leads into the first part of Marjan Venema's answer:
I's say that a model per table is just recreating your database in a class structure. It is known as a anemic model and considered an anti-pattern.
An Anemic Domain Model is an anti-pattern. A "model per table" as Venema suggests could be seen as "recreating your database," however it is absolutely incorrect to say this alone is an Anemic Domain Model.
From Martin Fowler:
The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters.
The key factor in an anemic domain model is a lack of behavior, or methods, on the Domain Model classes.
That is because classes are intended to have both data and behaviour. If you restrict your models to a single table, where do you put the code (behaviour) that needs to deal with data and behaviour from multiple tables?
Again, you can, and should, put behavior in your Domain Models, even if they only map to one table. Behavior that affects multiple tables really affects multiple objects that happen to map to multiple tables. Domain Driven Design is an approach to precisely the same problem Venema mentioned: "where do you put the code (behaviour) that needs to deal with data and behaviour from multiple tables?"
And the answer is an Aggregate Root. Martin Fowler states:
Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate.
A "cluster of domain objects" can also be viewed as "Domain Models that map to multiple tables." Behavior that affects multiple tables should be defined on the Aggregate Root - A class that encapsulates the "thing" that affects multiple tables or objects:
Again, from Martin Fowler:
An aggregate will often contain mutliple collections, together with simple fields.
To answer the OP's original question:
... would creating a Model per database table be considered good practice? That way methods aren't written twice.
I would say this is a good place to start, but be aware that your schema and object model do not have to match 100%. The object model should be more concerned with implementing and enforcing business rules. The schema should be more focused on storing business data in a modular and scalable way.
A model per controller would not be good practice, although there is a variation of model called a View Model that does fit into the Controller layer. A View Model is a reorganization of the Domain Model to fit a certain kind of display, be it a web page or form in a GUI application.