3 ms·
That's a really good point. I have, certainly in Rails projects[1], seen the strangest databases. They are SQL databases that are useless outside the rails ap
by geebee 9y ago
That's a really good point. I have, certainly in Rails projects[1], seen the strangest databases. They are SQL databases that are useless outside the rails application. You actually can't query them in a relational sense, you have to go through the app and its methods of querying, transforming, and merging data, before you understand what it means.
In short, the developers more or less used the ORM to serialize and object and write it out to disk. The persistent data basically makes no sense on its own, it has to repopulate the objects before it can be accessed in any meaningful way. There's little doubt that the devs behind these project had very little understanding of what an RDMBS actually is.
And if you don't, then I suppose NoSql makes sense, because your data is never relational - not because it the relational model wouldn't be helpful, but because the developer can't see the relational model in the data stored, and is incapable of structuring it this way.
I remember this idea (paraphrasing)[2] - the data will outlast the application, and the application will most likely outlast the developer.
To me, this led to a design principle - the database should always be useful outside the context of the application. If you want information about the data you're storing, the DB should be a very, very useful place to get it. I'm not ruling out the value of the app! There are lots of ops you'd want to do as a combination of code and data, lots of UI, plenty of things. But if your data is useless and nonsensical unless your app transforms it, that is probably a sign of a big mistake[3]
[1] I love rails, and I like ORMs. They save me so much typing compared to the old days of JDBC. It turns out it's not all that hard to create a well organized relational database through generators, and if you prefer to design the DB separately, it's not hard to map models to db tables. It really only gets out of control when people are essentially designing an RDBMS through generators and an ORM, but have no idea what idea what it all means on the backend.
[2]https://blog.jooq.org/2014/01/02/why-your-data-will-outlast-your-sexy-new-technology/ https://blog.jooq.org/2014/01/02/why-your-data-will-outlast-...
[3] probably
- bdcravens 9y ago> That's a really good point. I have, certainly in Rails projects, seen the strangest databases. They are SQL databases that are useless outside the rails application. You actually can't query them in a relational sense, you have to go through the app and its methods of querying, transforming, and merging data, before you understand what it means. When I converted our application to Rails, I had a database that was pretty home-grown, as we were using a language/framework where you tended to write raw SQL. While I was able to tweak the model files to work with our schema, in most places I found it too challenging to construct ActiveRecord queries, and ended up writing a lot of raw SQL (or rather, copying it from previous iteration). Initially I thought I was doing it wrong because it wasn't Railsie enough, but realized that our database is our asset, and Rails is secondary. We do a lot of ad-hoc querying and report writing, so I definitely think database-first is the way to go in our use case.