You think it's better to do 501 queries to retrieve 500 cars rather
than 1 which has a join? I have to disagree. If you're pretty sure
you're going to need to use the driver, then joining the two tables is
the logical approach IMO.

It'll cause far more queries though. I would have thought that would
actually mean heavier network traffic than fewer queries returning the
same total amount of data in effectively bigger chunks.

Note that this isn't an O-O problem at all. Once you add in tricks like
caching and prefetching, you have to start wrestling with problems of
data going stale: "If I prefetch / cache, how do I keep up with changes
in the database? How do I make sure that the data within my application
is current with the data in the database?"

Depending upon your application, the answer may range from "I don't
care. I don't need to keep current with changes to the DB," to "I have
to fetch every time because I need to be as current as possible with
the DB." At this stage, the questions and problems are the same whether
you're writing an O-O application or a 3GL application.

The difference I would submit, is that O-O requires more careful design
in this regard, as it's harder to immediately understand what
operations will result in database fetches. If you design your objects
(as I did mine) so that a property reference:

Driver d = car.Driver;

may result in a database fetch, it's very difficult to know, looking at
the code, where trips back to the database may occur. This doesn't make
the O-O approach somehow inferior. All it means is that you have to
take more care in architecting your solution. We're using a horribly
slow ODBC connection, and we've managed to optimize our trips back to
the DB. It can be done.

One change I would recommend is this: don't use a property, use a
method:

Driver d = car.GetDriver();

I suggest this because in several cases we discovered that we wanted to
be able to regulate the amount of information coming back for an
object. In the case of a Driver, you may want merely a minimal object
that stands in for a driver and knows the driver ID, but contains no
additional information. Or, you might want everything about the driver.
The first requires no trip to the database, while the second does.
Wouldn't it be ugly if your architecture required client code to force
a trip to the database when all it wanted was a marker representing a
driver? So, we did something like this:

Driver d = car.GetDriver(DriverPart.Minimal);

or to get a full driver:

Driver d = car.GetDriver(DriverPart.All);

We have other objects that allow fetching of various subsets for
various purposes. Of course, if you're doing a full read up front and
caching all drivers, then this level of control isn't necessary.
However, for objects that are always fetched on first read, it can be
very useful. It also provides a visual clue of potential trips back to
the DB.

The truely OO approach is that each class has the knowledge to load and
save its own information.  As an object is filled (vehicle, for
example), it tells its Driver subclass to load its data based on the
provided Driver ID.  This is a very sound OO design, but can adversely
impact the performance of the system.

There is no shame in having the Vehicle class also load/save the Driver
information, also.  The Vehicle class's Fill() method would also
instantiate and fill a Driver object.

Arguments for the truely OO approach will depend upon the real design
of your system.  A simple Vehicle/Driver sample can easily be argued
both ways.  Consider the "bigger picture" that your system represents.
What are the real tradeoffs for your design if you don't do the true OO
approach?  How many users will be using the system at the same time?
How often is any given vehicle loaded?  How many vehicles are returned
at a time?  Will the users only be working with one vehicle at a time?

Chris