Database classes for job offers
Using DAOs


  The problem that I have is that these objects all need to be stored in a database, and I need methods to retrieve the information, create the objects and return them. Since it does not make sense - at least to me with my limited experience in OOP - for an object to have access to the database and be able to fetch itself, I'm using a Database class for each of my main objects that are stored in the database : CompanyDatabase, CandidateDatabase, OfferDatabase.


You are right that it would not make sense for an object to have access to the database and fetch itself, and you have more or less the right approach.
The classes that perform the database operations are commonly called "DAO" -- data access object. (I recommend to rename those classes to CompanyDao, CandidateDao, OfferDao.)

It's not common to make the data accessor methods static.
If you use DAO instances instead of static method references,
then you get a very flexible design where you could change the backend of your operations by simply passing a DAO instance that implements the same interface, but instead of a database, it transfers data from a web service, or a csv file, 
or via radio transmissions from the moon.

Class design

Avoid public fields in classes, like $id and $name in Company.
Fields are an implementation detail of a class,
and should not be easily manipulable from outside,
but strictly through dedicated accessor methods.

Working with SQL

Avoid SELECT *.
It's recommended to name the columns you need explicitly,
for two reasons:


Prevent wasted bandwidth between your program and database fetching unnecessary columns
Make sure you receive the columns in the right order, regardless of their ordering in the table


The SELECT query is from a table called companies,
but the UPDATE query is into a table called compagnies.
I suspect one of them is a typo.
In any case,
some frameworks recommend naming tables with singular words,
for example in this case I'd go for "company" instead.