Simple MySQL table design

Question

I think I should be counted as database newbie, so read the question as a newbie question. I currently create a table, which holds environment variables for a number of hosts, like this:

create table envs ( 
  host varchar(255), 
  envname varchar(255), 
  envvalue varchar(8192), 
  PRIMARY KEY(host, envname)
);

Very simple, one table holding all the data I need. Common operation is to get all the environment variables for a given host, another is to get a given environment variable for a given host, third example operation would be to get a given environment variable for all hosts and list duplicates.

Performance is not expected to be an issue, it's going to be maybe tens of hosts, dozens of variables per host, average max 1 query per second.

Now I've read that having composite primary key is not necessarily a good idea. Is this true for above use case? If it is true, how should I change the database design? If not, is the above one-table database fine for the purposes I listed above?

Answer 1

I don't see a problem here with the primary key. The semantics of a primary key is to uniquely identify the non-key attribute values for the key values. As I assume that for one host and one envname there is at most one envvalue the primary key makes perfect sense.

It could be that some people argue against composite primary keys because they are afraid of performance issues. However performance considerations should never influence the choice of the primary key. Many database systems automatically create an index structure for the primary key; the choice of this index structure can influence performance. However this choice can mostly be changed manually and should be done at a later point if you really have performance issues.

Your one-table design and choice of primary key is fine.

Answer 2

Now I've read that having composite primary key is not necessarily a good idea. Is this true for above use case?

No. Use a composite primary key on (host, envname) .

If it is true, how should I change the database design?

N/A.

If not, is the above one-table database fine for the purposes I listed above?

Yes: it's known as the Entity–Attribute–Value model .

Answer 3

It's a bad idea, because you store unique values (host, envname) several times.

What if you were to change the hostname from srv01 to *srv01_new*? You'd have to change every ocurrence of srv01 in your table. And what if, some day, you decide you need to create a new table that holds additional information about every single host.

Now, if you change the hostname, you have to change those information as well.

To get to your question: It's not an issue of performance , but of normalization .

Databases should generally be normalized as far as possible. If you are intrigued enough, read on .

You should create one table for your hosts, having a unique id (int) as primary key and a unique (index) name as the hostname.

Your table should then only reference the id of the host, not the name . This way, your hostname is only stored once in your whole database and can be altered to whatever you desire, without breaking other tables.

---

If your environment names are unique, too, you should create another table for those, having the same layout as the hosts table (id, name).

Your combination table then stores the id of the host and the id of the environment , along with the value. You must of course keep the combined primary key, so every combination of host/environment is unique and easily indexable.

Then, you have a many-to-many-relationship with additional attributes and perfect normalization.