In practice, I've seen three strategies, two of which you mentioned.

Use one table per inheritance tree with all possible attributes and a "type" column that specifies the class of the object.

Pro: Fast database actions. Easy to "upgrade" the class of an object (i.e. promote a student to teacher, though if you need to do this regularly, you should probably not use inheritance anyway). Stores all attributes in exactly one place.

Con: possibly wastes space, gets confusing if you have a largish number of subclasses. You should probably not use this if you want to represent "the ultimate base class" (Object/UNIVERSAL) in your database.

Use one table for each class with only the additional attributes and the object-id in the subclass' table.

Pro: allows for larger inheritance-trees to be modeled in the database. Usually stores all attributes in exactly one place.

Con: makes efficient selecting on multiple attributes an "interesting" problem. Retrieving all attributes of an object is fairly expensive if the inheritance tree is large.

Use one table for each class with all attributes for that class in the representing table.

Pro: allows for larger inheritance-trees to be modeled in the database. Can do reasonably efficient selects on multiple attributes.

Con: not very efficient if you want to retrieve multiple subclasses. Stores inherited attributes in multiple tables (especially nasty for updates/inserts if you have large fields).

In summary: OO-relational mappings are not as clear-cut as they appear on first glance. Which system is best depends on your typical use. You always have to make trade-offs and in complicated systems you will want to write your own queries for certain actions that just don't map well.

update: note that some databases *cough* postgres *cough* support something called table-inheritance, which might be an interesting alternative solution.