3 ms·

I would lay some of this at the feet of the fad for object-relational mapping, too. Trying to deal with object/relational impedance by sticking an object-orien

I would lay some of this at the feet of the fad for object-relational mapping, too. Trying to deal with object/relational impedance by sticking an object-oriented API in front of the database, and then using that to shoehorn OO ways of organizing and accessing data into an RDBMS, is a great way to place an upper bound on what kind of performance you can get out of the database. It also makes (what should be) routine schema migrations much more painful than they need to be. I think that that can explain a lot of the perceived success people were seeing with many document stores.

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.
bdcravens 9y ago
Indeed. I'm redesigning a database in Postgresql, and I'm taking the approach of building the best schema, and I'll tweak the ORM (ActiveRecord in Rails in our case)to work with that, as opposed to the other way around. (Currently we're probably 80% raw SQL)
goalieca 9y ago
I’m not sure why object oriented databases were a thing other than people liked to write OOP. The fact there is such a huge impedance between the structured data and management code seems to be a huge demonstration of cognitive dissonance in favour of OOP.
- tabtab 9y ago
  Part of it is that DBA's got a bad reputation for bottlenecking projects for many different reasons. Some of it legitimate, as they wanted to make sure schema design was consistent, properly normalized, and followed org standards; but some DBA's were control-hungry. Therefore, developers tried to minimize their need to go through a DBA by doing more data-ish things inside the application itself. That's more of a staff management problem than a technology problem, but OOP had the "fad cred" of the time and often bowled over DBA's. The pendulum has started to swing the other way as reinventing the database & querying in applications has proved messy.

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.

bdcravens 9y ago

Indeed. I'm redesigning a database in Postgresql, and I'm taking the approach of building the best schema, and I'll tweak the ORM (ActiveRecord in Rails in our case)to work with that, as opposed to the other way around. (Currently we're probably 80% raw SQL)

goalieca 9y ago

I’m not sure why object oriented databases were a thing other than people liked to write OOP. The fact there is such a huge impedance between the structured data and management code seems to be a huge demonstration of cognitive dissonance in favour of OOP.

tabtab 9y ago
Part of it is that DBA's got a bad reputation for bottlenecking projects for many different reasons. Some of it legitimate, as they wanted to make sure schema design was consistent, properly normalized, and followed org standards; but some DBA's were control-hungry. Therefore, developers tried to minimize their need to go through a DBA by doing more data-ish things inside the application itself. That's more of a staff management problem than a technology problem, but OOP had the "fad cred" of the time and often bowled over DBA's. The pendulum has started to swing the other way as reinventing the database & querying in applications has proved messy.