Are Rail's database tools really helpful?

[Denis BEURIVE]

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

--
Posted via http://www.ruby-forum.com/.

[Frederick Cheung]

On Wednesday, November 21, 2012 10:56:58 AM UTC, Ruby-Forum.com User wrote:

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

[Scott Ribe]

On Nov 21, 2012, at 3:56 AM, Denis BEURIVE wrote:

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

1) the methods are not that complicate

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

--
Scott Ribe
scott...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice

[KlausG]

Hi,

Am Mittwoch, 21. November 2012 11:56:58 UTC+1 schrieb Ruby-Forum.com User:

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 ;-)

Greetings