Choosing a Database Schema for Polymorphic Data (2024)

(www.dolthub.com)

46 points gm678 | 2 comments | 09 Jul 25 00:13 UTC | HN request time: 0.415s | 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 #

1. IceDane ◴[09 Jul 25 05:07 UTC] No.44506483[source]▶

>>44506003 #

Want to elaborate on how you're going to magically disappear the inherent polymorphism in your problem domain every time?

Sometimes you can indeed view things from a different perspective and come up with a simpler data model, but sometimes you just can't.

replies(1): >>44511901 #

2. acquiesce ◴[09 Jul 25 16:23 UTC] No.44511901[source]▶

>>44506483 (TP) #

There is no polymorphism. There’s nothing polymorphic about the 2 types of payments. And furthermore you’re likely to run into situations where you have to have both an insured amount and an uninsured amount for a given treatment/procedure. So now you’re dealing with arrays of heterogenous data.

The process for handling the two cases is distinct. This is the classic OOP issue of trying to use a Shape object to represent both Box and Sphere. Just don’t. Stick with transaction/linear code and use transforms as it makes sense for certain cases (ie, MVVM style). Handle the two cases distinctly so there is no room for ambiguity.

People get this confused and they think it can’t be simpler.

↑