Question

(on mysql database), I want to have a table which contains different variables for different languages, e.g. text direction, is first letter of names always capital, should I url-encode links and so on.

A human would think of this like this:

id | lng | text direction | url encode | 1st letter cap |
---------------------------------------------------------
1  | en  | ltr            | 0          | 1              |
2  | he  | rtl            | 1          | 0              |
3  | fr  | ltr            | 1          | 1              |

But this way I might find out I have to add more columns, which I understood is not very good db design. another option is maintaining a fixed 2 columns table of ‘id’ and ‘lng’, and then this table:

lng id | var            | val |
-------------------------------
1      | text direction | ltr |
1      | url encode     | 0   |
1      | 1st letter cap | 1   |
2      | text direction | rtl |
(and so on)

Or maybe even three tables: language names and IDs, var names and IDs and the table above – when replacing var text description with var id.

I might even want to forget about storing var text description and just use ids direclty when I query, but this doens’t seems very human-friendly.

which is the way to go?

Answer 1

Your second example is using the Attribute-Value Model. It can be useful if (as you have said) you’ll need to often add more columns and/or if most of your entities don’t need all the columns and would be otherwise leaving them NULL.

The downside is it makes queries more complex to write, which is why I try to avoid it wherever possible – I think simplicity is more important that worrying about having to add a column once in a while. Unless new columns need to be added very frequently, for example, if your end-users need to add new fields at runtime, then I would go with your first option – a language table with the language attributes and a foreign key to that whenever you need it. You probably don’t even need the id column, just use the lng as a natural key.

Schemaless databases like MongoDB handle this problem a lot better. It has no concept of columns so you can start storing new data whenever and if you have an entity that doesn’t need all the fields you just don’t specify them.