2 ms·

I think the fundamental problem is that Rails is based on active hostility towards database engineering. It's the same thing that MySQL did early on. It works

I think the fundamental problem is that Rails is based on active hostility towards database engineering. It's the same thing that MySQL did early on. It works very well in some cases but has a serious cost attached that few people want to talk about, namely the fact that things suddenly become problematic when you want to use the RDBMS to effectively share data between diverse applications. The thing is that once you make this tradeoff, I wonder whether it is really that helpful to stick with an RDBMS at all, or whether NoSQL is a better option.

dasil003 15y ago
Good point, however at least ActiveRecord doesn't make the mistake of trying to utterly hide SQL from the user. Since moving to arel in Rails 3.0 things are very clean, logical, and not trying to do to much. It's not particularly hostile to serious SQL developers even if it doesn't have proper language-level tooling for advanced SQL. I think it's still a clear win over NoSQL where a one-size-fits-all solution is simply impossible and would send Rails off into the weeds.
- einhverfr 15y ago
  But you have an inherent tradeoff in ORM-land., You can either essentially build your database as an object store around your ORM or you can build your database and do real SQL coding. But at that point why use an ORM like Active Record at all?
  - masklinn 15y ago
    > But at that point why use an ORM like Active Record at all? Automatic type conversion and packaging of "rows" into hashes or objects, so you don't have to handle date parsing or integer conversions by hand and can call your utility methods or return your instances to whoever needs them. That's basically all Rails's `ActiveRecord::Base.find_by_sql` or Django's `Manager.raw` (linked to by murz) do. That's also the core/most basic layer of SQLAlchemy, and it's perfectly possible to use only that: SQLAlchemy has an Expression Language which is a direct translation of SQL into Python expressions[0] and an ORM built on top of that[1], and using just the expression language is perfectly OK if that's what you want. [0] http://www.sqlalchemy.org/docs/core/tutorial.html http://www.sqlalchemy.org/docs/core/tutorial.html [1] http://www.sqlalchemy.org/docs/orm/tutorial.html http://www.sqlalchemy.org/docs/orm/tutorial.html
  - einhverfr 15y ago
    Replying to Masklinn below: > But at that point why use an ORM like Active Record at all? Automatic type conversion and packaging of "rows" into hashes or objects, so you don't have to handle date parsing or integer conversions by hand and can call your utility methods or return your instances to whoever needs them. But this isn't really what I am getting at. Once you go down the ORM route and that means sacrificing database engineering for use of the ORM (and thus largely making your database into a single application part of the stack), then what benefit do you get from using an RDBMS? Wouldn't NoSQL be better? And if all you are getting is type conversion and hash<->relation conversion, why not use NoSQL? The issue is a specific one about a design tradeoff. You can do real db engineering (as high normalization of data as possible based on inherent functional dependencies of the data itself) or you can build your db schema around the object model of your app. If you do the latter, I am not sure you have a compelling reason to use an RDBMS, and if you don't have a compelling reason to use an RDBMS, you don't have a compelling reason to use an ORM at all. After all if I use MongoDB and simply serialize my objects into JSON or the like, then I get the same benefit but with better performance and less opacity. It seems to me that for an ORM to work the relational structure must be designed around what the ORM expects. Applying an ORM to something like a 5NF database designed for a very different application strikes me as fundamentally problematic. Is it just that you have the ability to hopefully put in some ad hoc reporting functionality later? What is the benefit?
    - dasil003 15y ago
      Note: If you click the link button you can reply directly even to new posts. > Once you go down the ORM route and that means sacrificing database engineering for use of the ORM This is where you're wrong. This is an all-or-nothing argument that isn't based in reality. The reality is you make choices at every level, and an ORM like ActiveRecord doesn't do much to prevent you from using the full database feature set at your disposal. Granted, if you do everything with stored procedures and foreign keys then you won't be able to use all of ActiveRecord's features, but you really can do things any way you want. > then what benefit do you get from using an RDBMS? Wouldn't NoSQL be better? Now assuming you lean more in the ActiveRecord direction and don't do much heavy database engineering, why no use NoSQL? Well, take your pick from the usual reasons. RDBMS systems are mature, performant, extremely rich for ad-hoc querying and, easy to administer, etc, etc. Just because ActiveRecord only explicitly uses 20% of the features of the typical RDBMS doesn't mean those features aren't extremely useful per se. The way I look at it is that using an RDBMS for almost any new project is a smart hedge, because an RDBMS is the most type of flexible data store. It will allow you to pivot more easily compared to a NoSQL store where things may be extremely scalable in the dimension that you foresee, but if you need to pivot your data model you are in for a massive rewrite. People complain about adding columns and indices to SQL databases vs the "agility" of just adding keys to Mongo or whatever, but honestly it's just a little busy work most of the time, it doesn't really hurt until your data gets huge, at which point you are going to be running into unanticipated bottlenecks anyway.

dasil003 15y ago

Good point, however at least ActiveRecord doesn't make the mistake of trying to utterly hide SQL from the user. Since moving to arel in Rails 3.0 things are very clean, logical, and not trying to do to much. It's not particularly hostile to serious SQL developers even if it doesn't have proper language-level tooling for advanced SQL. I think it's still a clear win over NoSQL where a one-size-fits-all solution is simply impossible and would send Rails off into the weeds.

einhverfr 15y ago
But you have an inherent tradeoff in ORM-land., You can either essentially build your database as an object store around your ORM or you can build your database and do real SQL coding. But at that point why use an ORM like Active Record at all?
- masklinn 15y ago
  > But at that point why use an ORM like Active Record at all? Automatic type conversion and packaging of "rows" into hashes or objects, so you don't have to handle date parsing or integer conversions by hand and can call your utility methods or return your instances to whoever needs them. That's basically all Rails's `ActiveRecord::Base.find_by_sql` or Django's `Manager.raw` (linked to by murz) do. That's also the core/most basic layer of SQLAlchemy, and it's perfectly possible to use only that: SQLAlchemy has an Expression Language which is a direct translation of SQL into Python expressions[0] and an ORM built on top of that[1], and using just the expression language is perfectly OK if that's what you want. [0] http://www.sqlalchemy.org/docs/core/tutorial.html http://www.sqlalchemy.org/docs/core/tutorial.html [1] http://www.sqlalchemy.org/docs/orm/tutorial.html http://www.sqlalchemy.org/docs/orm/tutorial.html
- einhverfr 15y ago
  Replying to Masklinn below: > But at that point why use an ORM like Active Record at all? Automatic type conversion and packaging of "rows" into hashes or objects, so you don't have to handle date parsing or integer conversions by hand and can call your utility methods or return your instances to whoever needs them. But this isn't really what I am getting at. Once you go down the ORM route and that means sacrificing database engineering for use of the ORM (and thus largely making your database into a single application part of the stack), then what benefit do you get from using an RDBMS? Wouldn't NoSQL be better? And if all you are getting is type conversion and hash<->relation conversion, why not use NoSQL? The issue is a specific one about a design tradeoff. You can do real db engineering (as high normalization of data as possible based on inherent functional dependencies of the data itself) or you can build your db schema around the object model of your app. If you do the latter, I am not sure you have a compelling reason to use an RDBMS, and if you don't have a compelling reason to use an RDBMS, you don't have a compelling reason to use an ORM at all. After all if I use MongoDB and simply serialize my objects into JSON or the like, then I get the same benefit but with better performance and less opacity. It seems to me that for an ORM to work the relational structure must be designed around what the ORM expects. Applying an ORM to something like a 5NF database designed for a very different application strikes me as fundamentally problematic. Is it just that you have the ability to hopefully put in some ad hoc reporting functionality later? What is the benefit?
  - dasil003 15y ago
    Note: If you click the link button you can reply directly even to new posts. > Once you go down the ORM route and that means sacrificing database engineering for use of the ORM This is where you're wrong. This is an all-or-nothing argument that isn't based in reality. The reality is you make choices at every level, and an ORM like ActiveRecord doesn't do much to prevent you from using the full database feature set at your disposal. Granted, if you do everything with stored procedures and foreign keys then you won't be able to use all of ActiveRecord's features, but you really can do things any way you want. > then what benefit do you get from using an RDBMS? Wouldn't NoSQL be better? Now assuming you lean more in the ActiveRecord direction and don't do much heavy database engineering, why no use NoSQL? Well, take your pick from the usual reasons. RDBMS systems are mature, performant, extremely rich for ad-hoc querying and, easy to administer, etc, etc. Just because ActiveRecord only explicitly uses 20% of the features of the typical RDBMS doesn't mean those features aren't extremely useful per se. The way I look at it is that using an RDBMS for almost any new project is a smart hedge, because an RDBMS is the most type of flexible data store. It will allow you to pivot more easily compared to a NoSQL store where things may be extremely scalable in the dimension that you foresee, but if you need to pivot your data model you are in for a massive rewrite. People complain about adding columns and indices to SQL databases vs the "agility" of just adding keys to Mongo or whatever, but honestly it's just a little busy work most of the time, it doesn't really hurt until your data gets huge, at which point you are going to be running into unanticipated bottlenecks anyway.