Site Collections by default are stored in the content database for the web application. The diagram below illustrates this.
Using the administration user interface you cannot create a new site collection with its own content database. This may lead you to create many web applications for your SharePoint site collections so that each one has its own database that can be backed up using SQL Server database backups and SharePoint backup and restore.
Restoring the backups may become awkward as you will have to restore the whole content database unless you have a 3rd party disaster recovery tool in place.
STSADM has an operation called "CreateSiteInNewDB". The command line definition for this command is:
stsadm -o createsiteinnewdb -url <url> -owneremail <
someone@example.com> [-ownerlogin <DOMAIN\name>] [-ownername <display name>] [-secondaryemail <
someone@example.com>] [-secondarylogin <DOMAIN\name>] [-secondaryname <display name>] [-lcid <language>] [-sitetemplate <site template>] [-title <site title>] [-description <site description>] [-hostheaderwebapplicationurl <web application url>] [-quota <quota template>] [-databaseuser <database username>] [-databasepassword <database password>] [-databaseserver <database server name>] [-databasename <database name>]
for example:
The diagram below illustrates the content boundaries when create site collections using stsadm -o createsiteinnewdb.
Of course there are considerations when deciding on which approach to choose. When you have site collection webpart like the Content Query WebPart are limited to aggregating content within the current site collection. The diagram below illustrates this.
If you decide to implement divisions of the company or site applications using site collections you just need to be aware of this, as its not alway fully understood. One workaround is that the MOSS search picks up all data stored in the site collections because of the way the content source is defined.