13 ms·

This seems like an aimless rant. Rails (and Hibernate to my knowledge) uses SQL for exactly what he recommends: filtering, aggregation, and joining. The RDBMS i

This seems like an aimless rant. Rails (and Hibernate to my knowledge) uses SQL for exactly what he recommends: filtering, aggregation, and joining. The RDBMS is a very real and concrete concept in ActiveRecord. If you don't know SQL, it's going to make it difficult to get beyond the most basic ActiveRecord functionality.

mattmcknight 17y ago
Agreed. It's complete ignorance on the author's part to suggest that Rails and Hibernate serialize objects into a single cell. acts_as_nested_set even provides a decent way of dealing with tree structured data in a relational store. His second part is off base as well, the challenges of serialization in strongly typed languages have little to do with wire protocols. He seems to be suggesting that adding a translation layer would solve the problem. It rather seems that would still fail if deserialization were used, as the translation layer would then become brittle. Rather it would seem to be more wise to step away from a serialization based persistence approach, while it might be a good idea for wire protocols, since the data is more ephemeral.
- loup-vaillant 17y ago
  About the serialization, I understood he basically said "don't use that". Not that an explicit, manual translation layer would solve any problem. It just makes you aware of it. Translation layers are brittle even if they are automatic. The only solution is to have a protocol (or file format) that change as little as possible. An automatic marshalling facility doesn't encourage you to do so. I see one case where automatic serialization is harmless, though: when you have the guarantee that the program producing the data and the program receiving it are of the same version and don't talk to the outside world. Temporary files used to recover crashed sessions are a good example.
fauigerzigerk 17y ago
ActiveRecord and Hibernate can certainly do everything SQL can do. But the modeling and data access patterns they encourage are inconsistent with the strengths of relational databases and the relational model. The point of using a relational database system is to think in sets of tuples because doing that makes life simpler (for some types of tasks). You apply one of a handful of set operations to a set and you get back another set of tuples. Once you start assigning types and custom operations to particular combinations of attributes, you lose this recursive transformability and hence the simplicity of the model. What you get is a horribly complex monster. The whole OO idea is a tangled mess. ActiveRecord and Hibernate do their best to help you view the database as a tangled mess as well.
- ubernostrum 17y ago
  Well. I've written at length about this in the past, and basically my opinion comes down to there being two ways to approach this. One is driven by the application, the other is driven by the database. The application-driven approach is, I believe, the vastly more common use case: you have some things in your code (objects, data structures, whatever) and want some way to persist them and fetch them back later according to their properties, so you use a SQL-based DB because, hey, you can get them for zero monetary cost (PostgreSQL, MySQL, SQLite, etc.), every language has ways to speak SQL and every developer on your team knows SQL. The database-driven approach is, in my experience, less common: you start with the database, design it meticulously, take full advantage of the relational model and the features it and your DB offer, build as much as possible in the DB layer and then let people write applications which talk to it. Both you, and the author of the reply in the email this thread links to, seem to inhabit the latter use case. And that's fine; I know people who do that stuff and I respect it. Where the problem comes in is that you have a tendency to assume that your use case and your approach are or should be the only use case and approach. Which is, frankly, wrong. There are plenty of situations where the application-driven approach does just fine and will take you a very, very long way (and when it breaks down, it probably will not break down because you need to switch to the database-driven approach; it'll break down because of other things), and where the database-driven approach really isn't a great fit (for various reasons).
  - fauigerzigerk 17y ago
    I don't disagree with your application driven vs data driven distinction and I agree that it's impossible to say in general which one is better. My experience is that it is rare for an application to stand on its own for long. Data has a longer life span than application code, but anyway, both scenarios do exist and both are legitimate. But making this distinction says little about what are good design principles in order to reduce the complexity of a system. My opinion is that data and relationships among data items should be represented uniformly on the application level as well as on a broader data management level. Creating one API per combination of attributes leads to a combinatorial explosion, an increase in coupling and unnecessary mental load. It makes generic transformation of data and querying very difficult indeed. We need to work with few general purpose data structures that are easy to reason about. And no, I'm not assuming that my approach should or even could be the only one. But I think the standard reply of "one size doesn't fit all" or "use the right tool for the job" has become all too fashionable. There are many tools for the same job, so I have to have an opinion and I have to choose. I'm not an authoritarian person at all, so I don't care the least if you make a different choice ;-)

mattmcknight 17y ago

Agreed. It's complete ignorance on the author's part to suggest that Rails and Hibernate serialize objects into a single cell. acts_as_nested_set even provides a decent way of dealing with tree structured data in a relational store. His second part is off base as well, the challenges of serialization in strongly typed languages have little to do with wire protocols. He seems to be suggesting that adding a translation layer would solve the problem. It rather seems that would still fail if deserialization were used, as the translation layer would then become brittle. Rather it would seem to be more wise to step away from a serialization based persistence approach, while it might be a good idea for wire protocols, since the data is more ephemeral.

loup-vaillant 17y ago
About the serialization, I understood he basically said "don't use that". Not that an explicit, manual translation layer would solve any problem. It just makes you aware of it. Translation layers are brittle even if they are automatic. The only solution is to have a protocol (or file format) that change as little as possible. An automatic marshalling facility doesn't encourage you to do so. I see one case where automatic serialization is harmless, though: when you have the guarantee that the program producing the data and the program receiving it are of the same version and don't talk to the outside world. Temporary files used to recover crashed sessions are a good example.

fauigerzigerk 17y ago

ActiveRecord and Hibernate can certainly do everything SQL can do. But the modeling and data access patterns they encourage are inconsistent with the strengths of relational databases and the relational model. The point of using a relational database system is to think in sets of tuples because doing that makes life simpler (for some types of tasks). You apply one of a handful of set operations to a set and you get back another set of tuples. Once you start assigning types and custom operations to particular combinations of attributes, you lose this recursive transformability and hence the simplicity of the model. What you get is a horribly complex monster. The whole OO idea is a tangled mess. ActiveRecord and Hibernate do their best to help you view the database as a tangled mess as well.

ubernostrum 17y ago
Well. I've written at length about this in the past, and basically my opinion comes down to there being two ways to approach this. One is driven by the application, the other is driven by the database. The application-driven approach is, I believe, the vastly more common use case: you have some things in your code (objects, data structures, whatever) and want some way to persist them and fetch them back later according to their properties, so you use a SQL-based DB because, hey, you can get them for zero monetary cost (PostgreSQL, MySQL, SQLite, etc.), every language has ways to speak SQL and every developer on your team knows SQL. The database-driven approach is, in my experience, less common: you start with the database, design it meticulously, take full advantage of the relational model and the features it and your DB offer, build as much as possible in the DB layer and then let people write applications which talk to it. Both you, and the author of the reply in the email this thread links to, seem to inhabit the latter use case. And that's fine; I know people who do that stuff and I respect it. Where the problem comes in is that you have a tendency to assume that your use case and your approach are or should be the only use case and approach. Which is, frankly, wrong. There are plenty of situations where the application-driven approach does just fine and will take you a very, very long way (and when it breaks down, it probably will not break down because you need to switch to the database-driven approach; it'll break down because of other things), and where the database-driven approach really isn't a great fit (for various reasons).
- fauigerzigerk 17y ago
  I don't disagree with your application driven vs data driven distinction and I agree that it's impossible to say in general which one is better. My experience is that it is rare for an application to stand on its own for long. Data has a longer life span than application code, but anyway, both scenarios do exist and both are legitimate. But making this distinction says little about what are good design principles in order to reduce the complexity of a system. My opinion is that data and relationships among data items should be represented uniformly on the application level as well as on a broader data management level. Creating one API per combination of attributes leads to a combinatorial explosion, an increase in coupling and unnecessary mental load. It makes generic transformation of data and querying very difficult indeed. We need to work with few general purpose data structures that are easy to reason about. And no, I'm not assuming that my approach should or even could be the only one. But I think the standard reply of "one size doesn't fit all" or "use the right tool for the job" has become all too fashionable. There are many tools for the same job, so I have to have an opinion and I have to choose. I'm not an authoritarian person at all, so I don't care the least if you make a different choice ;-)