Well, every resort will have a max price, a min price,
one location, and many activities. So you can get away
with three tables.
resorts resort_activities activities<
-------- ---------- ----------
resort_id* resort_id activity_id
name activity_id description
location
This isn't too bad for a start. I personally recommend
something like postgresql for this. DBD::CSV is good, but
I don't know how it does with multi-table relations.
You could really do all of this with one table instead of
three, but your database wouldn't be 'normalized'. Look
into the concept of 'normalization' before you design
anything that needs to grow to any useful size.
--Gabriel
