Question

So I’d like to display a user’s country or a country dropdown menu.

Let’s say I have a users table :

CREATE TABLE users
(
  "id" serial, --PK 
  "name" character varying,   
   ...  
  "country" integer --FK 
);

The country is a foreign key that rerefences the PK “id” column of “items_country” table

CREATE TABLE items_countries
(
  "id" integer,   --PK
  "text_en" character varying,   
  "continent" integer --FK to table "items_continent"
);

I always designed my database this way: some of my applications required near 100 kind of “items”.
For items with a very large set of values, I would create its own database table (“items_countries”) and grouping the others in one huge “items” table.

This approach pleased my clients who needed, via a database web-based administration, to change the label or to add a value in the items specific to their work. But consider that most of these items never change (countries, gender…), is it worth to store them in the database ?

What about an static array approach ? Pros: reduce the number of database tables ?, Cons: no foreign key, no delete cascade/verification.

It’s not about performance issues, because both method can result in caching, but rather a database/application design question.

What’s your approach for this ?

Answer 1

In my book, this really depends on the application and user needs. I have done both in the past.

Generally, if there is a reasonably small set of data that seldom changes, coding it in a library or a configuration file is the direction I would take. When the data gets too large or needs to be related to additional information, then I would likely put it in the database.

One thing I also do when figuring out which route to take is to list the pros and the cons of putting the information in code / in a database and then make a decision based upon the information that emerges.