Best gem for an existing mysql database

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

On 04/28/2011 05:24 AM, Iain B. wrote:

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

On 28 Apr 2011, at 20:42, Joel VanderWerf wrote:

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.

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.

More on sequel’s differences from AR:

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

Iain

Here is an ORM that works with MySQL