Best gem for an existing mysql database

[Iain Barnett]

Hi,

I've an existing MySql database, and not having used any of the major =
database gems like ActiveRecord, Sequel etc etc I was wondering which =
one would work well against an already built DB ?

The quicker I can get up and running the better. It would also be nice =
if I could bypass whatever sugar it has to run SQL directly, so I can =
just plug in any exising queries that are lying around.


Any help on this is much appreciated.

Regards,
Iain=

 

[Joel VanderWerf]

Hi,

I've an existing MySql database, and not having used any of the major database gems like ActiveRecord, Sequel etc etc I was wondering which one would work well against an already built DB ?

The quicker I can get up and running the better. It would also be nice if I could bypass whatever sugar it has to run SQL directly, so I can just plug in any exising queries that are lying around.

Sequel and AR will both let you drop to the SQL level, if the model
level isn't quite right for what you want to do. I don't know about
DataMapper or other ORMs.

One thing I've always liked about sequel is that there is an
intermediate level, between models and SQL: datasets with their chained
query methods. Some examples:

http://cheat.errtheblog.com/s/sequel

The documentation for datasets:

http://sequel.rubyforge.org/rdoc/files/doc/dataset_basics_rdoc.html

Rather than use models, I often find it easier to think in relational
terms and code in ruby, and that's what sequel's datasets let you do.

Another factor to consider, when the database precedes the app, is
whether the ORM layer supports the schema. IIUC, AR doesn't support
composite primary keys without using an extra library. Sequel does
support composite primary keys (this was very helpful to my team just in
the last few weeks). This difference may not matter much, but it's
something to be aware of.

More on sequel's differences from AR:

http://sequel.rubyforge.org/rdoc/files/doc/active_record_rdoc.html

 

[Iain Barnett]

=20
Another factor to consider, when the database precedes the app, is =

whether the ORM layer supports the schema. IIUC, AR doesn't support =
composite primary keys without using an extra library. Sequel does =
support composite primary keys (this was very helpful to my team just in =
the last few weeks). This difference may not matter much, but it's =
something to be aware of.

This is a deal breaker, or maker in this case as the database does hold =
several composite keys.

=20
Rather than use models, I often find it easier to think in relational =

terms and code in ruby, and that's what sequel's datasets let you do.

I think this would suit my style of thinking too. I'm quite comfortable =
with SQL and sets and they seem to make more sense for a lot of problems =
than starting with objects, for me anyway.

=20
Sequel and AR will both let you drop to the SQL level, if the model =

level isn't quite right for what you want to do. I don't know about =
DataMapper or other ORMs.

=20
One thing I've always liked about sequel is that there is an =

intermediate level, between models and SQL: datasets with their chained =
query methods. Some examples:

=20
http://cheat.errtheblog.com/s/sequel
=20
The documentation for datasets:
=20
http://sequel.rubyforge.org/rdoc/files/doc/dataset_basics_rdoc.html
=20
=20
More on sequel's differences from AR:
=20
http://sequel.rubyforge.org/rdoc/files/doc/active_record_rdoc.html

Thanks, I'll give those a look. I really appreciate the time you've =
taken to give me a good answer, it's difficult to tell from just reading =
the docs / looking at examples, as they all *seem* to do what you want, =
and right now I don't have the time to get far down the road before =
failing.

Thanks again.

Regards,
Iain=