Marnen, thanks for the feedback! Perhaps I should do more googling on the subject... and I may be ignorant here but,
In terms of some of your comments: Indexing is VERY db (and db version) specific. You may have situations where a btree index is more appropriate rather than a bitmap index. With Mysql (correct me if i'm wrong) there is no support for bitmap indexing. With Postgres there is... And with MySQL it very much depends on which storage engine your using. Rails uses InnoDb by default? In some cases I may actually like to use MyISAM, which excels at super fast select queries, ideal for data warehousing situations. I agree that putting large amounts of business logic in the DB is not a good idea. I've never liked using, creating or maintaining insanely complex stored procs... (thank you SQLServer 2000) IMO, most of the business logic should be in the application code - but then again - in situations where you just need to, for example, capture the state of a record before a update/delete for an audit trail, no rails code can compete with a simple trigger.... coding that in Rails (similar to acts_as_versioned or is_paranoid) just seems counter intuitive to me. Enough hijacking... I'll check out hobos, thanks! And maybe start a new thread to more concisely state my thoughts... Regards, Johan De Klerk On Wed, Dec 30, 2009 at 12:17 AM, Marnen Laibow-Koser <[email protected]>wrote: > Johan De Klerk wrote: > > I may be completely out of line here... but > > > > "WTF? Don't you use migrations? That's what they're for." > > > > made me think that migrations aren't the be all and end all. > > How did what I wrote lead you to that conclusion? > > > There are > > ALOT > > of things you cant do with migrations when it comes to database specific > > deployment. eg. triggers, user defined functions, even views... > > Migrations can do all of these things. The migration framework is > extensible, as witness rails_sql_views and the various foreign key > plugins, and as a last resort, you can put literal SQL in the > migrations. > > > and even > > things like index creation is limited when using Postgres and MySQL or > > even > > SQLServer. > > What about index creation doesn't Rails let you do? > > > > > I know and realize Rails is opinionated software... but IMHO the > > community > > could benefit from using the power these dbms solutions offer. > > Yes. But I don't think putting large amounts of logic in the DB is a > good idea. Key constraints are one thing; big stored procedures (such > as I used to write) are quite another. > > > How about > > a > > DSL type plugin - not only enhancing migrations, but extending > > activerecord > > to embrace the DBMS rather than treating it as "just a storage > > mechanism". > > Check out Hobo's "rich types". And I think there's a case to be made > that ActiveRecord *does* embrace the DB; it's just that a lot of Rails > developers don't. > > > > > Sorry for hijacking here, just my two cents... > > > > Best, > -- > Marnen Laibow-Koser > http://www.marnen.org > [email protected] > -- > Posted via http://www.ruby-forum.com/. > > -- > > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<rubyonrails-talk%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
