Are Exclusive Arcs Evil?

I've just discovered this concept is called "exclusive arc".

Exclusive arc's coupling of "commentable" to the "page" and "post", doesn't fit best practices for programming languages. That's always felt like a code smell to me. But I am applying programming best practices to SQL table design, which might be incorrect.

The author linked a stack exchange post and I discovered GitLab's contributor guide to polymorphic associations which provides interesting arguments on the topic.

I've seen this pattern a few times, and it's cute, but I doubt "polymorphism", at least as defined and proposed in the article.

There inevitably comes a time while designing a data schema when it’s desirable to have an entity that can belong to one of a number of different types of entities. A Comment could belong to a Post or it could belong to a Page - therefore the Page and Post entities both share the characteristic of being commentable.

Huh. I think this skips an important analysis: why do you want to do this?

And it is crucial to know the answer to be able to find out the proper database design!

Besides normalization, I like to say that database design should make your business logic map to simple queries. (And contrary to what many people say, joins are not particularly complex! they are just... wordy) The exclusive arc pattern would allow you to query over both page comments and post comments... and that's it. If there are other differences between page comments and post comments, it's going to make the comments table annoying to work with.

---

There are other patterns that you can do.

page_comments and post_comments tables are likely the simplest. Django is the ORM I'm more familiar with, and it provides abstract base classes that could help with this.

Sometimes you can extract a parent entity and have a table for that. (So you could have comments, page_comments, and post_comments, with the primary key for the page and post comment tables referencing the parent comments table. The foreign keys to pages and posts would be in the child tables, common data would be in the parent.)

To decide on the proper structure to use, you should try writing a couple of queries that represent what your application normally does- likely one of the patterns will work better, and likely you should choose that one.