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