7

polymorphic relationships are fucking stupid. it's a great way to make your shit more complex and less maintainable for no benefit other than having 1 less table (which also makes queries slower since they can't be optimized correctly).

Comments
  • 3
    They are alright when used properly in correct places. But I agree, it's hell when used improperly
  • 2
    They solve a real problem but "let's make everything flexible" always leads to a horrible architecture. See the same with interfaces.
  • 3
    They're often the result of applying OOP principles to databases. Which isn't a great thing to do.

    I've noticed two things with backend devs:

    1. A tendency to think that new tables are worse than new columns. This results in over-generic, wide tables.

    2. The belief that because code must be DRY, schemas must also be DRY. Sure, in your code you should abstract common behavior through composition or inheritance — but there's no shame in having multiple very similar SQL tables.

    Just because both "users" and "companies" can be invoiced, doesn't mean you *must* at any cost have just 1 invoices table.

    Even if the invoicing is functionally very similar for both models.

    And especially with more abstract use cases where polymorphism is often used (logging, audits) you might want to actually split it over multiple tables, for performance reasons.

    Still. It's a hard problem. They didn't coin a name like "object relational impedance mismatch" for something that's trivial.
Add Comment