Sitting in the junction, throwing rocks into air, looking for the path to go. If you want to store data, were you should put it ().
I would say, if you’re starting to implement new application, don’t rush randomly. Mismatch between Object and Relational models is rather huge, and it’s very easy to ignore; i.e. assume naively that some ORM mapping will magically fix the problem. No, ORM mapping doesn’t magically fix the issue, but adds another extra indirection layer, which makes design even more complex (which will be hit when design needs to scale above toy test implementation, into actual workloads).
If using relational DB, either application design must match relational model, or design will suffer when trying to scale up. However, due to various reasons, relational DB is almost always cheapest way to bootstrap new project, since tool support, etc. is simply widest for it. And, I would say that such is fine. However, beware of danger of being stuck into relational model. After draft prototyping carefully analyze model, and see if mismatch between relational and object model is sustainable (with some knowledge of what application should be doing also in the future). Naturally such analysis requires some understanding of how relational DB works and actually how ORM mapping can work. If developer’s don’t have any clue of what happens behind the curtains of ORM mapping, then, well, shortly said, project will be doomed eventually. In the end, everything depends from what is data access pattern of application. Here also, if developer’s don’t have any clue about it (but assume magic fairies to do it), then project shall be doomed also.
So, literally, don’t paint yourself into corner with DB selection of project.
Also, before starting to fish further in the water than necessary. Check also capabilities of your relational DB first. For example, Postgresql – Inheritance. However, beware that meaning of ”object-oriented” in the context of relational DB can be somewhat different/restricted than what it’s in O-O language (ex. java). So that might be actually solution, but rather just add another mapping to be worried about. Hint: Class hierarchies in O-O language can be easily refactored, while in reality doing same refactoring in DB might be much more difficult, so if you rely into such, then DB model can actually start to be like huge chain in the ball, attached into your leg, forbidding to do needed changes.