Abstraction vs application level

Hi there,
my goal is to describe in a single database a booking system for different kinds of resources.

Let's suppose only three kinds of 'facilty': hotels, restaurants and car rental.
The need is for implementing a uniform fares scheme.

create table facility (
# it describes every single facility (hotel, restaurant, car rental)
id int,
name varchar,
category int,
address varchar,
.....
)

create table categories (
id int,
name varchar # [hotel | restaurant | car rental | ...]
)

create table resources (
# it should describe hotel rooms but also restaurant menus and cars to rent with relative fares...
id int,
facility int,
name,
type,
price
)

create table calendar (
resource int,
start timestamp,
end timestamp
)

The problems in this (absolutely not-working) design are:
- 'type' field should express the differences between a menu and a room but then where to store explicitely those differences?
In another DB table or in the application layer?
- 'price' field is not uniform: a menu is a one-shot price, a room is calculated on a per-day basis, a car on a per-hour basis.
- 'start' and 'end' timestamps in the calendar are a good way to express the use of every kind of resource, but there
are problem on the user side: a menu has no duration (it could be defaulted in the back-end, anyway) but a room has a
per-day scheduling while a car has not...

I don't think there's an easy way to have an abstract scheme to describe every kind of resource, maybe there's not. I'd only
like to see if there's a good idea out there or a simple one that I'm just missing....

I also thought of implementing a different logic at application level depending on the categoriy value of the facility but I dont'
want to (I'd like not to) write a new and different piece of code every new category the application user creates...

What about this all?

Bye bye

For the price problem:

you can store the "1 unit price" and then you moltiply it per days or items. In this way you solve the problem linked to a menu item.
You have to store the items number and the single item price!

Calendar:

You don't need to store calendar information for every Resource. It's an information needed only on some kind of Res so why to store it when is not applicable?

Type field for resources:
A new table with description and other informations. For example you can store there if calendar is applicable or if is a "one-shot priced".

Ciao,
DARKWAVE