I would add, consider how you want to partition your data (that is put in separate databases). A consideration is size and what you may or may not want to sync with DTTG.
I agree with @rkaplan and in my ‘work’ database, I have to group everything to do with a single client project. I use tags for document types (like report, meeting minutes, proposal etc.) and can use smart folders to list these (or search).
Some folk will go for everything in one database, but I found I got a big jumble of tags. For my cookbook, the groups are types of dish (curries, burgers, deserts etc.) and tags for ingredients. When it was all in one database getting ‘cabbage’ (a food tag) next to ‘contract’ (a work tag) got annoying, so having cookbook in its own database means the tag list in the navigator made sense (all ingredients) and in the work database it is all document types etc.
I actually have several different databases, all which make logical sense for dividing the type of data. Another one is a database for all my bird notes and lists where tagging is based on location. An issue with tags for me is remembering them all, but with separation of the data into different databases, I can have a logical and/or different tagging approach for each database that I can remember!