How to properly organize table schema for data with "inheritable" properties?

I came with some background in C++ so let me clarify the "inheritable" properties in context of my question. I have data which is used to setup and control some equipment (so-called "instrument methods", or "method properties" in my vendor's terminology). I have different equipment from different vendors, however, most of the properties are just the same. Because now I deal only with single instrument type I store all of the method properties directly in one table where each column represents some property while rows contain all necessary data for single "instrument method" record. For example, my columns may be the following: *temperature*, *flow*, *percent_b*, *gas_flow*, *gas_type*. But soon I will be dealing with several types of instruments so this question naturally arises. Let's review the following example. 1. Method of equipment **B** contains (*b*) all of the properties of the method of equipment **A** (*a*) plus some extra own parameters (*b1*). So I can say that **A** is a direct ancestor of **B**: **A** -> **B**; *b* = *a* + *b1*. 2. Method of equipment **C** contains (*c*) only some of the properties of the method of equipment **A** (*a1*) plus some extra own parameters (*c1*). So I can say that **A** and **C** both have common ancestor **X** in the past: **X** -> ... -> ... -> **A** and **X** -> ... -> ... -> **C**; *c* = *a1* + *c1* Case number 1 represents **B** being direct mod/upgrade of **A** (e. g. instruments from the same vendor, just consequent models) while case number 2 represents **C** being in the same class of instruments as **A** (even from different vendors but pretty much the same). I know how to easily implement this with class hierarchy in C++ with just adding extra fields and other data structures where needed but I have no clue how to properly implement this in case of DB tables (if that's important I'm using MariaDB). As for now I have an idea of possible solution. I've decided to store data for specific instrument models in separate specialized tables, e. g.: 1. Table **MODEL_A** contains the following columns: *id*, *temperature*, *flow*, *percent_b* 2. Table **MODEL_A1** contains the following columns: *id*, *temperature*, *flow*, *percent_b*, *percent_c*, *percent_d* 3. Table **MODEL_B** contains the following columns: *id*, *temperature*, *gas_flow*, *gas_type* Also I need to store enumeration of supported equipment types (instrument models, in other words) in separate table. Finally, instead of storing all of possible data in one basic table (like with an example at the very beginning) I should store just the following rows of data in it: *id*, *instrument_type*, *method_id*. And here arises other complication. If I use only three columns - ID, reference to the instrument type (which is stored in separate table), reference to the actual data row in method table for specific equipment type - there should be some mechanism to ensure data consistency. I know how to apply foreign key constraints in simple cases (the whole column refers to another in second table) but I don't know how to tie these constraints with one extra constraint - selection of instrument type. Imagine that: end user of DB decides to change equipment type of the record in basic table. That action can invalidate foreign key reference because now we should refer to another table at all and it may (and, most likely, will) not contain proper data at old ID reference. I can prohibit changing instrument type at all, though, it isn't convenient and practical (much better solution would be to make necessary actions in GUI - I can highlight incompatible fields and hint next steps for end user). But in any case I can't leverage the benefit of using ON DELETE and ON UPDATE clauses together with the whole foreign keys idiom because different rows in my basic methods table will refer to the different tables in DB which AFAIK is not supported in MariaDB (or any other RDBMS). It looks like I shall track the whole integrity by hand in my backend/frontend code. So, I have the following questions: 1. Is such approach viable at all? 2. Is there a way to have references to different tables for a different rows of data? 2. Is there much better way to implement this in a RDBMS like MariaDB? 3. Are there RDBMSes much more suitable for such a task?