0

I have done some preliminary reading.

Config files vs database tables
Type to use for "Status" columns in a sql table

Tables:

[video]
    id
    title
    format_id (foreign key)
    language_id (foreign key)
    aspect_ratio_id (foreign key)

[formats]
    id
    name

[languages]
    id
    name

[aspect_ratios]
    id
    name

The last 3 tables (formats, languages, aspect_ratios) aren't going to change much (if at all). i.e. I might add a new language when we have support for it.

So is it a good practice to extract those types of tables (references only, hardly any updates/inserts) into a standalone yaml file and have the application logic to deal with the views? Or should I keep everything in the DB to maintain the data & relational integrity at the (small) cost of table joins?

Community
  • 1
  • 1
poweratom
  • 2,270
  • 23
  • 25

2 Answers2

2

Do you need to enforce the referential integrity (i.e. foreign keys) on these tables? If yes, then keep them in the database and let the DBMS enforce it for you. Ditto for other kinds of integrity.

Do you intend to JOIN these table with others? If yes, keep them in the database and let the DBMS do the heavy lifting.

Do you need to update them in a transactional way (albeit rarely)? If yes, then let the DBMS provide ACID for you.

Do you need to backup this data? If yes, let it happen together with the regular database backup.

Do you need to ensure this data is same for all clients? If yes, a central location such as database is an obvious candidate.

Etc, etc...

Branko Dimitrijevic
  • 50,809
  • 10
  • 93
  • 167
1

If they rarely change and can be defined before or at deploy time I prefer files, either YAML or JSON.

berngp
  • 36
  • 2