They're not very big (maybe 15 or 20 chars, can't remember exactly), and are strings. Note: this could change. Nothing in the OAuth spec describes how to generate tokens and secrets, nor what they look like. I expect they'll always be strings, but I might want to make the column a little bigger than currently necessary for contingency.
If you store them in the database, you need some other way of authenticating the users so that you know whose tokens to pull out and use so they can't be used maliciously. If you already have that and it's working then that makes sense, otherwise you might want to rethink it.
Another way to do it is to store their tokens in a cookie, the drawbacks of that are that (if you don't encrypt them or use SSL) they are traveling over the net in the clear, and if they change computers, browsers, or delete their cookies you have to make them go through the whole OAuth process again.
For a website with no other auth, I would encrypt them and store them in a cookie. If you already make them log in, then associate both the token and secret with the login and store them in the database.
There are other ways, too. You could use a randomly generated ID like a GUID/UUID in a cookie to point to a record in a database with the tokens if you didn't want to use encryption. All in all, it depends on how you want your application to behave from the users' point of view.
Make sure you handle the case where the user de-authorizes your app too.