=== Option A
This is the simplest and would be flexible enough to accommodate any other restrictions we would like to add to a particular block. I'm not a fan of EAV but in this particular case it suits us well and it is not unheard of in our current database layout.
**//Data types here are illustrative, and open to change.//**
{F18449173}
---
=== Option B## ipblocks_restrictions
| Field | Type
| ------------|-----
| ir_block_id | int
| ir_type | int
| ir_value | int
`ir_type` will be an `int` representing one of two values //(page, namespace)// and it will unlikely support anything else in a foreseeable future
## ipblocks
The advantage here is that we can make use of FK constraints and "possibly" some performance gains over EAV. The disadvantage is that for every new restriction we want to add, a new table has to exists. This is also not very flexible or useful for things that are not stored in the DB (like namespaces)| Field | Type
{F18479895}| -------------|--------
| ipb_sitewide | tinyint
A `bool` named `sitewide` will be added to `ipblocks` to indicate if the block is sitewide or partial.