Reputation: 2302
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 ?
Upvotes: 0
Views: 432
Reputation: 148
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.
Upvotes: 3