I have a database that has a single table with around 1.8 billion records (yes, a B not an M) in it right now. There's another table in the same DB with around 740 million records.
The total DB size is around 300GB.
The server is running just fine. It is a quad core Xeon with 32GB of RAM and a very very fast disk array.
As far as tips and tricks:
Seriously think about why you want that much data. It is a LOT to deal with at any one time. Also, once it is set up forget about changing indexes, columns, or pretty much anything else. Those operations take too long to complete on tables this large.
Seriously think about why you want that much data. Yes, I'm repeating myself. Find another way if possible. Recovering a DB of this size is a complete PITA and may take a long time... Like a day or so.
If possible, rollup your data in some meaningful way. If using the data for trending, try and get your calculations down as soon as possible and throw away the underlying data. Of course, if the underlying data has to be kept for some reason, store it in a flat file or something else.
Don't use any form of encryption with this DB size. If your data requires that, then plan on spending a lot of money on hardware (as in the $1M+ range).
Take your time and test different recovery models.. Right down to hard booting the server in the middle of transactions. See what happens. I found that "simple" works best for me.
My data is mostly transactional, and, quite frankly, not mission critical. If the entire db suddenly fell on it's face, well, a few eye brows might be raised by nothing major.
The DB is servicing about 150 requests/second. 99.999% of which are writes. Nightly, we roll the information obtained up into summary tables. There is a small dashboard site which is used by maybe 5 people to view what the historical / daily summaries are.
What kind of information are you really trying to find?