There is certainly data you don't want to put into a relational model.
There are domains where it is essentially impossible to create a reasonable relational model. For example where a class references many, quite different, classes. In the relational world you need many kinds of different keys to many other tables and the table names. And even then you need to bounce out of the relational world to get the results. In the object world references are uniform.
There are a lot more cases where a reasonable relational model exists but it is not supported by the mature SQL databases. A very large matrix, a highly structured document, source code etc.
And there are more cases than that where it will be no longer be worthwhile to create an SQL model if the nosql databases mature. Such as when when an Object, JSON or XML model needs to exist. I think this is close to 100% of enterprise applications.
Comments
There is certainly data you don't want to put into a relational model.
There are domains where it is essentially impossible to create a reasonable relational model. For example where a class references many, quite different, classes. In the relational world you need many kinds of different keys to many other tables and the table names. And even then you need to bounce out of the relational world to get the results. In the object world references are uniform.
There are a lot more cases where a reasonable relational model exists but it is not supported by the mature SQL databases. A very large matrix, a highly structured document, source code etc.
And there are more cases than that where it will be no longer be worthwhile to create an SQL model if the nosql databases mature. Such as when when an Object, JSON or XML model needs to exist. I think this is close to 100% of enterprise applications.