3 ms·

This is why I don't think of database as an interface. Instead, create functional interface with some business meaning (REST API, GraphQL, a Java interface - wh

This is why I don't think of database as an interface. Instead, create functional interface with some business meaning (REST API, GraphQL, a Java interface - whatever suits a particular use case), which will be versioned and properly maintained with backward compatibility where possible (which is, I think, almost always possible). It doesn't cancel a proper DB design though, but helps a lot when you need to change it. Or move to another DB engine altogether. You know, every problem can be solved with another level of abstraction. No sarcasm, I think it actually holds here.

tabtab 8y ago
While a many-to-many DB relationship can in theory model a 1-to-many relationship via constraints and/or domain logic coding, it seems kind of anti-YAGNI to me. Being that ANY 1-to-many relationship can potentially change into being many-to-many, which ones do you "pre many" and which ones are left 1-to-many? My crystal ball is not that powerful. If it were, I'd be competing with Warren Buffett instead of puzzling over database design.