You are right..

SPSite = sitecollection

SPWeb = site within a sitecollection, thus can also be subsite of a site.

It's much easier if you take the SDK as the beginning point: SPSite (Site Collection) may contain other webs (but not other Site Collections). If you go further you see there is this SPSite.RootWeb property - it's the website you see when you type your Site Collection's URL. Site Collection is quite abstract: you cannot see it inspite of using it's URL: all you get to see is the RootWeb. Then there are the Webs (called Sites by Microsoft: so Site Collection contains Sites) - SPWeb in the SDK. Webs can contain other Webs.

Site Collection is the beginning point of your hierarchy tree: there is nothing about it you could see through the GUI. If you use the SharePoint Manager you will run into Web Application (IIS Virtual Server): a Web Application may contain multiple Site Collections, so:

1. Web Application

1.1 Site Collection (SPSite)

1.1.1 Site (SPWeb)

1.1.2 Site (SPWeb)

1.2 Site Collection (SPSite)

1.2.1 Site (SPWeb)

1.2.1.1 SubSite (SPWeb)

1.2.1.2 SubSite (SPWeb)

Hope it's clear now.

Think of a site collection as a container and boundary for features and permissions.

You would create a site collection under an existing site collection instead of creating a subsite if you wanted to maintain a heirarchy with the url, but wanted a different site collection administrator and default set of permisions and/or a different set of site collection features (master pages, site columns, etc..).

Remember that all of the elements of a site collection, sites, lists, and document libraries, by default inherit their permissions from the site collection.

HTH...