parsonsmatt / parsonsmatt.github.io

My Github pages website
Other
77 stars 25 forks source link

Questions about Sum Types in SQL #42

Open tysonzero opened 4 years ago

tysonzero commented 4 years ago

After playing around with a variety of approaches I am leaning towards using shared primary keys as you suggest in this post.

However with that said I have a few questions:

Avoiding primary key collisions

In my case the superclasses are rarely known too far in advance. For example initially groups and users were distinct with no shared class, but later features such as commenting mean that they are both now "authors" or "identities" and need to share a superclass. Unfortunately there are collisions between the primary keys, so I can't use shared primary keys in a backwards compatible way.

For this reason I was considering using a single source of keys that are unique DB-wide. I am leaning against GUIDs due to how insane they would be in URLs or to speak aloud. With that in mind I am considering just a simplistic rerolling random number generator. A DB-wide sequence also seems workable, although I don't like how predictable and scrapeable the id's would be.

I was curious how reasonable of an approach this is, and also what the best general approach was for implementing it. I was considering a universal superclass Object table, or perhaps a separate non-table system that generates and keeps track of these id's (similar to how a sequence works).

How to model this in Persistent/Esqueleto

It seems like I'm probably going to use some external SQL and some manual conversion functions between subclass primary keys and superclass primary keys. However it does seem like I have to do quite a lot of outside intervention and would prefer if there was a nicer approach.


It may be worth including answers to the above in the blog post, or if not I'd still greatly appreciate what you have to say about them. Thanks!