Is a one column table good design?

In terms of relational algebra this would be a unary relation, meaning "this thing exists"

Yes, it's fine to have a table defining such a relation: for instance, to define a domain.

The values of such a table should be natural primary keys of course.

A lookup table of prime numbers is what comes to my mind first.

Yes, it's certainly good design to design a table in such a way as to make it most efficient. "Bad RDBMS Design" is usually centered around inefficiency.

However, I have found that most cases of single column design could benefit from an additional column. For example, State Codes can typically have the Full State name spelled out in a second column. Or a blacklist can have notes associated. But, if your design really does not need that information, then it's perfectly ok to have the single column.

I've used them in the past. One client of mine wanted to auto block anyone trying to sign up with a phone number in this big list he had so it was just one big blacklist.

If there is a valid need for it, then I don't see a problem. Maybe you just want a list of possibilities to display for some reason and you want to be able to dynamically change it, but have no need to link it to another table.

One case that I found sometimes is something like this:

Table countries_id, contains only one column with numeric ID for each country.

Table countries_description, contains the column with country ID, a column With language ID and a column with the localized country name.

Table company_factories, contains information for each factory of the company, including the country in Wich is located.

So to maintain data coherence and language independent data in the tables the database uses this schema with tables with only one column to allow foreign keys without language dependencies.

In this case I think the existence of one column tables are justified.

Edited in response to the comment by: Quassnoi

_{(source: ggpht.com)}

In this schema I can define a foreign key in the table company_factories that does not require me to include Language column on the table, but if I don't have the table countries_id, I must include Language column on the table to define the foreign key.

There would be rare cases where a single-column table makes sense. I did one database where the list of valid language codes was a single-column table used as a foreign key. There was no point in having a different key, since the code itself was the key. And there was no fixed description since the language code descriptions would vary by language for some contexts.

In general, any case where you need an authoritative list of values that do not have any additional attributes is a good candidate for a one-column table.

I use single-column tables all the time -- depending, of course, on whether the app design already uses a database. Once I've endured the design overhead of establishing a database connection, I put all mutable data into tables where possible.

I can think of two uses of single-column tables OTMH:

1) Data item exists. Often used in dropdown lists. Also used for simple legitimacy tests.

Eg. two-letter U.S. state abbreviations; Zip codes that we ship to; words legal in Scrabble; etc.

2) Sparse binary attribute, ie., in a large table, a binary attribute that will be true for only a very few records. Instead of adding a new boolean column, I might create a separate table containing the keys of the records for which the attribute is true.

Eg. employees that have a terminal disease; banks with a 360-day year (most use 365); etc.

-Al.

Mostly I've seen this in lookup type tables such as the state table you described. However, if you do this be sure to set the column as the primary key to force uniqueness. If you can't set this value as unique, then you shouldn't be using one column.

No problem as long as it contains unique values.

I would say in general, yes. Not sure why you need just one column. There are some exceptions to this that I have seen used effectively. It depends on what you're trying to achieve.

They are not really good design when you're thinking of the schema of the database, but really should only be used as utility tables.

I've seen numbers tables used effectively in the past.

The purpose of a database is to relate pieces of information to each other. How can you do that when there is no data to relate to?

Maybe this is some kind of compilation table (i.e. FirstName + LastName + Birthdate), though I'm still not sure why you would want to do that.

EDIT: I could see using this kind of table for a simple list of some kind. Is that what you are using it for?

Yes as long as the field is the primary key as you said it would be. The reason is because if you insert duplicate data those rows will be readonly. If you try to delete one of the rows that are duplicated. it will not work because the server will not know which row to delete.

The only use case I can conceive of is a table of words perhaps for a word game. You access the table just to verify that a string is a word: select word from words where word = ?. But there are far better data structures for holding a list of words than a relational database.

Otherwise, data in a database is usually placed in a database to take advantage of the relationships between various attributes of the data. If your data has no attributes beyond its value how will these relationship be developed?

So, while not illegal, in general you probably should not have a table with just one column.

All my tables have at least four tech fields, serial primary key, creation and modification timestamps, and soft delete boolean. In any blacklist, you will also want to know who did add the entry. So for me, answer is no, a table with only one column would not make sense except when prototyping something.

Yes that is perfectly fine. but an ID field couldn't hurt it right?