←back to thread

44 points gm678 | 3 comments | | HN request time: 0s | source
Show context
acquiesce ◴[] 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 ◴[] 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(1): >>44507138 #
1. ozgrakkurt ◴[] 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 #
2. setr ◴[] No.44510085[source]
Only the first strategy shoves it into the same table? The fundamental problem is record A can have type X Y or Z, with each type having additional metadata. You could flatten the model and have a table for each type X Y Z and query them independently, and pay the cost of duplicate schema structure and having to ensure they’re always synchronized manually (including any dependent tables), or you pluck out the common core and run into the article’s problem
3. gm678 ◴[] 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.