> Something thats always bugged me about relational database modelling is how you have to use table relationships for everything. This is pretty much the defin

> Something thats always bugged me about relational database modelling is how you have to use table relationships for everything. This is pretty much the definition of what a RDBMS is. The tables provide the relations via designated columns. Relation navigation is therefore possible in either direction given an established relationship and very often possible starting from any table in the pathological case. If this conceptual model is not appropriate, it is best not to use it to begin with. > This problem is heightened by the fact that a SQL table typically can't store composite types. That is not what RDBMS' are designed to do, even though many vendors now support some form of composite data types (like JSON). Just like a moped is not designed to move a family across a continent. Pick the persistent storage mechanism which best fits the problem at hand: - If the problem calls for a document structure, use a document database. - If the problem calls for a directed graph structure, use a graph database. - If the problem calls for a relational structure, use a RDBMS. - If the problem calls for some combination of the above, consider using multiple storage technologies. None are perfect, but starting with the most appropriate persistent store can eliminate the weaknesses others would introduce in the same solution space.