Actually, I could have cron run a ruby script first, sending out notifications to all authors whose postings are marked for deletion, and then have cron run a mysql command to move all deleted records to a table in another database. Would this be efficient? Thanks for all your help!
On Dec 7, 3:43 pm, liquid_rails <[EMAIL PROTECTED]> wrote: > Everytime I delete a record (i.e. move it to the deleted items > database) I want to send an email to the poster letting him know that > his post was deleted. Do you still recommend straight SQL for this? > > Thanks! > > On Dec 6, 3:43 pm, "John Bresnik" <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
