←back to thread

Choosing a Database Schema for Polymorphic Data (2024)

(www.dolthub.com)
46 points gm678 | 1 comments | 09 Jul 25 00:13 UTC | HN request time: 0.227s | source
Show context
acquiesce ◴[09 Jul 25 03:03 UTC] No.44506003[source]▶
I wouldn’t do this personally because the downstream code very often has to handle differences where polymorphism breaks and you end up having to query the type. Polymorphism shouldn’t be used for data, only behavior, and only in very specific circumstances. Subclassing is a different topic.
replies(2): >>44506205 #>>44506483 #
setr ◴[09 Jul 25 03:55 UTC] No.44506205[source]▶
You wouldn’t do what? Have polymorphic data to begin with? I don't see how you can choose to avoid the scenario that record A has one of several possible related metadata, other than just ignoring it and allowing invalid representations
replies(2): >>44507138 #>>44513913 #
ozgrakkurt ◴[09 Jul 25 07:18 UTC] No.44507138[source]▶
You can have different tables for different data. You don’t have to put all in same table
replies(2): >>44510085 #>>44510799 #
1. gm678 ◴[09 Jul 25 14:57 UTC] No.44510799[source]▶
I think the article alludes to the difficulty of this solution by discussing the need for invariants to be upheld when an insured patient becomes uninsured or vice versa. Different tables for each 'subclass' could be an option, but if that can change later on, you now need to move patients between the insured_patient and uninsured_patient tables and make sure you don't have duplicates.