I'm writing an app to store 'rulesets' in an SQL database. At the other end, the app will read the data and export it to specifically formatted text files.

The structure of a ruleset is always the same (uid, regex to match, action). A specific rule however will apply to a certain part of the application (eg. whitelist, blacklist, etc.)

Here's my dilema, do I store all the data in one 'ruleset' table with a field for where it is applied, or do I seperate it into seperate tables for each type of ruleset?

Option 1 - one table
uid | rule_type | match | action

Option 2 - multiple tables
uid | match | action

What are the pros and cons of each? To me, multiple tables (Opt2) is easier to work with in the UI and when writing out to files, but requires multiple structural changes if we want to alter how the rulesets are structured. Option 1 is straightforward but requires more WHERE clauses when using the data.

If it helps on performance grounds, there will be more reads than writes to the data.