Are Rail's database tools really helpful?

Hello,

I am looking at Rails for two days. I already use ZF (Zend Framework),
Codeigniter and ELGG.

My big concern is the ORM's.

In a real world application, you don't just play with one table at a
time. You have to write long SQL requests, with several tables : Using
ZF (Zend Framework) ou Codeigniter, I realized that the batabase layer
becomes a real pain in the ass.

Instead of writing a simple SQL request, you write a complicated set of
methods' invocations (with options...).

The resulting code is not easy to read. You think : I should write an
easy to read SQL request!

Some says : yes, but by using the database abstraction, you can change
you database easily (ex : from MySql to SQLServer)!

OK, but... Did you ever change your database ?

If you really need to migrate from MySql to SQLServer, then it means
that you have a *deep* problem. You may need to restructure your
database...

And what about "migrations" ?

Migrations keep track of structure's changes. OK, but why don't you just
keep your database's schema under SVN (or Git) ?

Migrations can be used to change the database's content. OK, but
everything is not reversible. And, by the way, you should always work on
the testing environment.

So, my question is :

Do you really use all the Rails' tools to manage your database ?

Can you use Rails without Active Record ?

Thanks,

Denis

Instead of writing a simple SQL request, you write a complicated set of

methods’ invocations (with options…).

The resulting code is not easy to read. You think : I should write an

easy to read SQL request!

Not sure I buy that.

I’d far rather write

Garment.join(:brand).where(:brands => {:published => true}, :category_id => jumpers)

than

find_by_sql(['select * from garments

inner join brands on garments.brand_id = brands.id

where brands.published = true AND category_id = ?’, jumpers)

And it only gets better as the query grows in complexity - building up strings is a pain in the arse, for example

Garment.where(criteria.reject {|k,v| v.blank?)

as opposed

to

criteria.collect |name, value|

“#{connection.quote name} = #{connection.quote value}”

end.join( ’ AND ')

Some says : yes, but by using the database abstraction, you can change

you database easily (ex : from MySql to SQLServer)!

OK, but… Did you ever change your database ?

If you really need to migrate from MySql to SQLServer, then it means

that you have a deep problem. You may need to restructure your

database…

It’s certainly true that changing database will always be a big effort, even if you write 0 lines of sql in your rails app.

And what about “migrations” ?

Migrations keep track of structure’s changes. OK, but why don’t you just

keep your database’s schema under SVN (or Git) ?

just storing the schema doesn’t always tell you how to apply changes to that schema

Migrations can be used to change the database’s content. OK, but

everything is not reversible. And, by the way, you should always work on

the testing environment.

So, my question is :

Do you really use all the Rails’ tools to manage your database ?

I do

Can you use Rails without Active Record ?

Absolutely. You could use data mapper for example or not use a SQL database at all. I’ve built apps that only used couchdb or mongo or that didn’t have a persistence layer of their own at all.

Fred

1) the methods are not that complicate

2) if you wish, you can just write SQL instead and get objects back

Hi,

In a real world application, you don’t just play with one table at a

time. You have to write long SQL requests, with several tables

No in my application I am not working with tables at all, I am working with objects,

e.g I have a customer object or an order object.

If I need a list of open order items for a customer I write:

items = customer.order_items.open.all

if I would use SQL I have to join the customer table with the order table and the order items table

using a where condition getting a more or less complicated sql string

Instead of writing a simple SQL request, you write a complicated set of

methods’ invocations (with options…).

The resulting code is not easy to read. You think : I should write an

easy to read SQL request!

So if you find the above code “not easy to read” please post the corresponding sql code :wink:

Greetings