Is gel mature enough to be used in prod? what's the main advantage it has over postgres?
acquiesce · 5h ago
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.
setr · 4h ago
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
ozgrakkurt · 1h ago
You can have different tables for different data. You don’t have to put all in same table
IceDane · 3h ago
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.
hot_gril · 5h ago
Definitely don't want to store types as columns in a DB, especially because of the inevitable thing that qualifies as two different types. In this situation, I'd usually take the first one (nullable cols) without much consideration. The DB doesn't need an xor constraint, but it can if you really want. New cols can be added without much impact on existing data.
And if the info is non-scalar, it's either option 2 (nullable FK) or 5 (JSON), depending on whether or not other things join with fields inside it.
hobs · 1h ago
First one gets messier faster than most, the fourth one generally grows the least crappily over time.
feitico · 1h ago
Just use NoSQL
MongoDB is great for this
4b11b4 · 3h ago
I learned a lot in a short time, thanks
j45 · 1h ago
I’m unsure why one wouldn’t use a polymorphic database for polymorphic data, instead of the gymnastics of bending a relational db.
Sometimes you can indeed view things from a different perspective and come up with a simpler data model, but sometimes you just can't.
And if the info is non-scalar, it's either option 2 (nullable FK) or 5 (JSON), depending on whether or not other things join with fields inside it.
MongoDB is great for this