Yea you really gotta pay attention when doing large/complex DB operations with ORMs - there's a general consensus (which I agree with) that you should avoid using straight SQL when using an ORM but there's lots of valid exceptions to this and its important to understand what they are. For example, the AR destroy_all literally iterates through every single record and calls a DELETE on it, so if you had 10K records, thats 10K database calls whereas you can do the exact same thing with a single call using TRUNCATE - 10K vs 1 call is very significant in terms of the load on your app / db (skipped over some details but you get the idea).
Another thing I see a lot is developers pulling in a couple thousand records and them trimming the result set down by some criteria in a related table (or specifics of a column) - not only does this clog up your memory map with stuff youll never use but its also additional work having to iterating over them all - in general I make it a habit of pulling out of the DB exactly what I need and nothing more on a single call - this usually involves an assortment of JOINs etc. there's also an assortment of anti-patterns in DB calls too (abusing embedded SQL calls, using IN clause on large arrays), i.e. the fun never ends.. ORMs tend to simplify database interaction greatly but there's a really dark side effect that results in decreasing knowledge abt what is really going on behind the scenes - regardless of tastes, everyone using an ORM should have a fundamental knowledge of relational DB concepts or its only a matter of time before youre going to get yourself in trouble. On Sat, Dec 6, 2008 at 12:57 PM, caike <[EMAIL PROTECTED]> wrote: > Actually it really would be a better way to go straight with SQL. > Forget what I said about ORM :) > > On Sat, Dec 6, 2008 at 5:22 AM, Steven Fines <[EMAIL PROTECTED]> wrote: > >> An even better solution would be to take advantage of mysql's selective >> replication feature. It'll be more complicated to set up, but if you're >> going to move a lot of rows on a regular basis and need the data moved >> now(tm) it'd be the way to go. >> If this is a one-off or once a year type task, I'd follow Mr. Bresnik's >> advice and use straight SQL. >> >> >> >> On Fri, Dec 5, 2008 at 7:33 PM, John Bresnik <[EMAIL PROTECTED]> wrote: >> >>> You should straight sql for this.. basically an insert statement with an >>> encapsulated select, doing with AR would be real expensive.. >>> >>> On Dec 5, 2008 1:38 PM, "liquid_rails" <[EMAIL PROTECTED]> >>> wrote: >>> >>> >>> Thanks, but I don't even know how to write the script or the code for >>> moving the records. Do you know of any websites or books that could >>> show me how to do this? >>> Thanks! >>> >>> On Dec 5, 11:34 am, Phlip <[EMAIL PROTECTED]> wrote: > John Bresnik >>> wrote: > > Put the code for m... >>> >>> >>> >>> >> >> >> > > > -- > Att, > - Caike > > > > > > --~--~---------~--~----~------------~-------~--~----~ SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby -~----------~----~----~----~------~----~------~--~---
