Seeking advice for how to structure a site

I'm new to Drupal, and am looking for advice on how best to structure
a web site I'm exploring moving thereto. My reasons for making the
change include a belief that putting this site into a CMS with a large
ecosystem around it will make it easier to maintain and enhance it in
the future. I obviously have a lot of learning to do before tackling
this job, but would like to get some good ideas of what sub-bits of
Drupal technology I should be trying to learn.

The site (http://ringing.org) is currently written using an ad hoc collection
of JSP files and custom tags, built around a MySQL database, with a
little static HTML and a few Perl and Python CGI scripts thrown in.
The structure of the site is defined by a single, large XML file that
is read and parsed at web server start up, or whenever the file is
changed, and that defines the several hundred pages that make up the
site, and their topology.

The heart of the site is a collection of about 8,000 change ringing
compositions, which are essentially mathematical formulae, each
presented in a tabular format. Characteristic examples can be seen at
http://ringing.org/main/pages/peals/major/spliced-surprise/9-22m.

They are divided up into pages of related compositions. The
distribution in pages varies according to the population of
compositions. For example, all those with the attribute know as stage
being 14 are gathered into a single page, while those with stage 8 are
spread across about 60 pages arranged in a tree with depth 3.
A Java servlet parses the request's URL and bounces it against the
parsed contents of the XML file to determine which pageful of
compositions to present.

The leaves of the tree of pages full of compositions consist of 5 to
100 compositions, one after the other. The intermediate nodes of this
tree are pages of links to the child pages.

The partitioning of compositions into pages can be relatively
complicated, involving joins across database tables, as some of the
relevant attributes are in a many to one relationship with the
individual compositions. Some compositions also appear in multiple
pages.

While currently compositions can only be added to the database by the
administrator, a long term goal is to allow suitably authenticated
users to validate and then add compositions to the database, too.
Indeed, the construction and maintenance of the complex forms and
work flow required to do this is one of the things I'm hoping Drupal
will simplify.

Scalability to large numbers of users is not important. It's rare for
more than two or three users to be hitting the site simultaneously,
and it averages only about 3,000 page hits a day. As change ringing is
an obscure endeavor, this number is unlikely to increase
significantly. Note that there is no commercial component to this
site, either.

However, it is reasonable to believe the collection of compositions
could grow an order of magnitude, as would the total number of pages
for browsing them.

An additional complication is searching. I currently extract keywords
from the various fields describing each composition, and populate a
table mapping them to pages. Presumably in Drupal I should have some
mechanism for attaching keywords to pages so the normal Drupal search
mechanisms can get a suitable result.

So, what I'm looking for advice on, is how best to implement something
giving a similar end user experience under Drupal.

Should I implement this portion of the site as a book? Should the
intermediate pages of the tree, not containing compositions but rather
links to child pages, be menus?

How should I handle the display of compositions? Do I need to write a
custom module to deal with them? Should it be one node per
composition, which nodes are then assembled into pages? Or should it
instead be a node is page, which contains multiple compositions all
sucked out of the database together?

Can I use CCK to build such stuff on top of the existing database? Can
I use Drupal's own taxonomy to mimic the attributes I'm currently using
in the database to partition things, possibly via Views?

Or should I arrange to copy things out of the database into Drupal's
own database? And there use Drupal's own taxonomy and Views?

Or something else entirely?

Are there any other modules that might help in this endeavor that I
should look into?

--
Don Morrison
"For most history is guessing, and the rest is prejudice."
-- Will Durant, _Our Oriental Heritage_