4 ms·
As someone who knows SQL pretty well, it amazes me how Rails applications are architected. Recently I needed to create a record without a primary key (as a nume
by trebor 15y ago
As someone who knows SQL pretty well, it amazes me how Rails applications are architected. Recently I needed to create a record without a primary key (as a numerical ID). This isn't an issue to the database, but Rails would die any time it attempted to either load or save an object. The exception this "id-less" record threw was so ambiguous that I spent upwards of 6 hours deciphering it. I solved the issue by including an unneeded ID field.
And another thing that amazes me is the frequent lack of indices. You want slow searches for specific values? Okay, you got it!
I know that it's tempting to avoid SQL and leave it 100% to the code generator—but the few edge cases you have with poor(er) performance could really get a boost with even minor understanding of SQL.
- addandsubtract 15y agoI gave up on Rails, because I didn't want to unlearn SQL / relational DB principles. Is there a good guide somewhere that will teach me how to stay in control of my DB schema with Rails and not do dumb shit the framework wants me to do?
- trebor 15y agoI haven't found one. At least with Rails 3 / ARel you can do queries like: Posts.where("posted_on BETWEEN ? AND ?", Date.current - 2.months, Date.current) But it still isn't the same. You can create a Rails app without an ORM, but then you must do all your queries and migrations in your own code. This is one of the reasons people stick with the suboptimal SQL: it's faster to generate and lets you iterate more quickly.