I have a table, A
, whose rows have a many-to-one relationship with several other tables. The rows in the other tables-- B
, C
, D
--each have many A
s. Each A
relates exclusively to another table. For example you never have an A
that relates to both a B
and C
.
Currently, the A
table is represented as a "flattened" sum-type where each row has a nullable AId
, BId
, CId
, & DId
. The "parent" of any given row in A
is determined by which one of these FK's in non-null.
This has been working fine so far. However, I have several new features to be implemented down the road which will also have many A
s.
My question is: is there a more extensible design than simply adding more columns to store FK's to these other tables?
You have a type of MUCK (massive unified code key)table, but only worse.
Instead of a table like this:
MUCK(aid, bid, cid, did, value1)
It would work better like this:
MUCK(table, id, value1)
The table is a,b,c, or d (or so on) and the id is the id within that table.
However, I really suggest you do some research on why MUCK and EAV tables can be a nightmare as you add requirements and features.
Here is a question I recently answered and a link to another that discusses why EAV (and even more, MUCK) is not always the best idea.
How to store custom entity properties in a relational database
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.