How to design a table that only needs a column?

I am creating a database table that'll have a list of all Tags available in my application (just like SO's tags).

Currently, I don't have anything associated with each tag (and I'll probably never have), so my idea was to have something of the form

Tags (Tag(pk) : string)

Should this be the way to do it? Or should I instead do something like

Tags (tag_id(pk) : int, tag : string)

I guess looking up on the table in the 2nd case would be faster than in the first one, but that it also takes up more space?

Thanks

I'd go for the second option with the surrogate key.

It will mean the table takes up more space but will likely reduce space over all assuming that you have the tag information as a foreign key in other tables (e.g. a posts/tags table)

using an int rather than a string will make the lookups required to enforce the foreign key more efficient and mean that updates of tag titles don't need to affect multiple tables.

Indexes work better with integers than CHAR/VARCHAR, go with a dedicated integer primary key column. If you need tag names to be unique you can add a constraint, but it's probably not worth the hassle.

You should go for the second option. Firstly, you never know what the future holds. Secondly, you may later want multiple language support or other things that makes the string-as-the-primary-key have a strange feeling around it. Thirdly, I like the idea of using a standard procedure for a table definition, ie. that there always is a column 'id' or 'pk'. It separates business from technology.

Quite possibly you'll have a faster lookup with the index being an integer. Further, consider making your index clustered for even further speedup.

I wouldn't emphasize too much on the performance issue though. As soon as a program starts talking to a database over the internet, you have a much bigger delay than 99% of all the queries of your database (of course with the exception of reporting queries!).

Those two options achieve quite different things. In the first case you have unique tags and in the second you don't. You haven't said what use TAG_ID is in this model. Unless you put in TAG_ID for a good reason then I'd stick with the first design. It's smaller, appears to meet your requirements precisely and Tag seems like a more obvious choice for a key (on grounds of familiarity and simplicity).