@spivonious: It all depends on the situation (like I said earlier, not every tool is a hammer because not every fastener is a nail).
Say you have 500 tables in your DB. Say one of them is a root table, and the primary purpose of this database is to store some very large and complex set of data that is built off the root. Say you also need to get that complex set of data back... how is this done for each?
- In a relational model, this will be a massive and potentially very complex SELECT statement with all kinds of JOIN clauses.
- In an object model, just ask for the root and you have everything.
That is just one class of problem. Relational excels in cases where you need to do reporting on this data. And frankly, either mechanism will ultimately work because (again as I posted earlier) Relational and NoSQL are duals.
right, if the specific case is one where relational does not work well then for sure I would never try and force it to fit.
in fact MS SQL has ways to handle cases like this, put a bit of tracing data in sql and use the filesystem links to store the "Blob" of non relational data on the file system and do what you need to with that chunk of storage.
in such a case I would only use sql for a some basic lookup and to track the native object list *if* doing that was helpful. if it was not then I would not force it.
I re-worked a game app one time where the OP used sql when it was 100% not needed. it was dumb as heck and made installing the app a pain.
used an in-memory object model and wrote some csv files to do reporting at the end of a run for the customer and the result was a faster, smaller app that did what they needed.
like you said it's not just nails and hammers. use the right tools for the job.