CSS-like dynamic properties cascading configuration table? Have an idea in mind, not interested in inventing an existing wheel, but can't find info on the subject so I'm turning to the community.
My goal is to define a &quot;dynamic properties cascading configuration table&quot;, which means the following:
I would like to maintain a metadata table with dynamic properties for a certain database table entities.
There are many properties and they may or may not exist for the entity. That is why they should be kept on a separate table.
Moreover, I would like to have configuration levels for that metadata table, e.g.: SYSTEM, TOP_LEVEL, MID_LEVEL, etc.
Let's say we have an online store system where we have brands, each having customers, each having shops.
We'd like to define a system-wide default property of a logo image URL.
This property may be different on the brand leve, customer level or the individual shop level.
The design for this table would be something like:
  id          // unique row id
  configType  // SYSTEM, BRAND, CUSTOMER, SHOP
  entityId    // ID of a user, a post, etc.
  key
  value
  valueType   // string, number, etc. - will be used for validations and parsing

Possible rows would look something like:
+----+------------+----------+----------+-----------------+-----------+
| id | configType | entityId |   key    |      value      | valueType |
+----+------------+----------+----------+-----------------+-----------+
|  1 | SYSTEM     | SYSTEM   | logo-img | sys-logo.jpg    | string    |
|  2 | BRAND      | brnd2    | logo-img | brnd2-logo.jpg  | string    |
|  3 | CUSTOMER   | cust81   | logo-img | cust81-logo.jpg | string    |
|  4 | SHOP       | shp76    | logo-img | shp76-logo.jpg  | string    |
+----+------------+----------+----------+-----------------+-----------+

So when searching for the logo image of shop shp76, which its parent is cust81, which its parent is brnd2, we would like to get the most nested level of configuration possible. shp76-logo.jpg in the above case.
If SHOP and BRAND config types wouldn't exist for this configuration, we would still prefer the CUSTOMER level value (cust81-logo.jpg) over the SYSTEM default.
+----+------------+----------+----------+-----------------+-----------+
| id | configType | entityId |   key    |      value      | valueType |
+----+------------+----------+----------+-----------------+-----------+
|  1 | SYSTEM     | SYSTEM   | logo-img | sys-logo.jpg    | string    |
|  2 | CUSTOMER   | cust81   | logo-img | cust81-logo.jpg | string    |
+----+------------+----------+----------+-----------------+-----------+

A postgres query would look something like:
  SELECT &quot;value&quot;
  FROM &quot;ConfigTable&quot;
  WHERE &quot;key&quot; = 'logo-img'
    AND &quot;configType&quot; IN ('SYSTEM','BRAND','CUSTOMER','SHOP')
    AND &quot;entityId&quot; IN ('SYSTEM','brnd2','cust81','shp76')
  ORDER BY (CASE status
            WHEN 'SYSTEM' THEN 1
            WHEN 'BRAND' THEN 2
            WHEN 'CUSTOMER' THEN 3
            WHEN 'SHOP' THEN 4
            END) DESC
  LIMIT 1


The config types we query are dynamic on a per-case basis. So if we'd like to query the value for the CUSTOMER level, we'll be able to use a different set of config types (e.g. without the SHOP type in this case)
This will allow us creating and maintaining different levels of configuration nesting for totally different configuration types as well (e.g. SYSTEM, WEEKLY, DAILY, HOURLY)

Issues with this solution:

The valueType and key do not change between rows, and are both duplicated.
The thought behind this is that this is already a pretty complex subject so introducing another id;key;type table would be another level of complexity.
How to maintain the data? (manually? write a configuration tool?)
How to query for multiple keys at the same time?
Is it possible to achieve with a pure SQL query or would code be required?
Performance
Should results be cached somewhere else (e.g. Redis)?
Is this a known subject which already has academy-level solutions?
I think you are describing an EAV model.
Data driven systems arent uncommon. But if the design allows the application to change without altering the schema then you're talking about EAV.
The advantage of this is that non-technical users can extend or customise an application and add attributes or fields without changing the actual schema.
The downside is that you rely on the app to enforce integrity and datatyping. Performance suffers too.
In my experience you see less of these as xml &amp; json have become more prolific.
Have a read of the various database design models at the bottom of this wikipedia page