4 ms·

> In most of the frameworks I've seen, to do so means to hack around the base framework. ActiveRecord [1][2] and Django [3][4] both feature logging sql and dro

• flomo 15y ago
  Well, RoR is living on Mysql defaults turd planet and therefore thinks Foreign Keys are a DRY thing and not a database optimization. So I'm pretty sure anybody with more than a trivial Rails app is manually indexing those columns. Either that or they are spending way more on their database than they should be.
  • einhverfr 15y ago
    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?
• rimantas 15y ago
  Also next version of RoR is likely to have auto EXPLAIN for slow queries.