[Nitro] OG vs Active Record

Jonathan Buch john at oxyliquit.de
Sun Aug 19 14:42:08 EDT 2007


> I'm relatively new to Ruby and am trying to decide between diving into
> ActiveRecord and OG.... I'd appreciate any advice.
> The useage case/scenario is:  Single 'amateur' developer, large
> numbers of databases, large databases (10'sGB/table, 10's tables/DB),
> multiple ruby scripts accessing the dbserver directly (no web
> interface - at this stage.)

Multi-database is not as thoroughly tested as single, but the number
(and also the sizes of the tables) do not make Og slow.  It's just how
much you need to transfer between Og/DB.
On startup time, if you stay below a 100 tables, it'll still be quite
ok on a halfway capable computer.  There are a few tweaks you can do,
but doing them means your app and db design is 'finished'.

> I understand that this is a little like asking a parent if their child
> is beautiful, but was hoping for some frank feedback on the following.
> 1) Am I right that OG largely overcomes the issues discussed in this
> (long) AR thread (I summarize a key issue below):
> http://rubyurl.com/xWb

Yes, by using Og basically _all_ your information is in the model file.
Even the DB layout is there (which is what differenciates Og from AR).

> and here:
> http://aralbalkan.com/764

Yep, this is exactly what Og does.  :)

> A summary of a key AR issue (for me) is:
> <quote>
> Whether its in migrations or in the DB schema, I have to specify all
> the columns as well as their lengths and unique constraints to have
> the database created.  Then I have to specify the validates_* rules
> in the model to match.  Finally I have to keep both of them in sync
> over time.
> Why not do it all inside the model and have that set up all the
> validates_* rules in a single step?
> </quote>

This certainly could be done and it has been asked for already on irc
some year ago.  I wasn't too sure about that back then, and I still
hesitate on that.  We could make it an option, `Og.auto_validations`
which then does the trick....  G?

Personally, I wouldn't use it largly because I tend to see some of the
validations as useless and time consuming (`uniq` for example, which is
again done on DB level, where it actually belongs to.
Some of the validations like 'belongs_to' (meaning it shouldn't exist
when the 'main' object disappears) can only be done via certain DBs
(like psql) with foreign key constraints.....  There's just so much
stuff the DB does better, that's what I think, anyway.  :P).

Anyway, like I said, the idea isn't all too bad, I'm just not sure
if it's worth it, as the models/validations don't get changed so
often (I draw stuff on real paper before doing DB work :P).

> 2) Has anyone compared the performance of AR vs OG. The following
> thread about AR's cpu useage, surprised me:
> http://rubyurl.com/vFz
> I see the same performance on my system (script attached).  Has anyone
> run this test under OG?

I'd love if you could adapt (I haven't had a look at it yet) that script
and run it on Og?

I would think that the performance of AR and Og could be quite comparable.
(Though, I could be horribly wrong, when I started with Nitro I thought
we were slower than rails, which turned out quite a wrong assumption ;))

But, I think you'll see the same 'behaviour' with Og and MySQL.  MySQL
is just too old, too optimized and there's too much movement behind it
for Og to really stress it.  At least that's my guess.  ;)

> 3) How well is MySQL supported (bearing in mind that OG is at 0.5), or
> is most development done with Postgresql?  On MySQL, how about the
> MyISAM and Memory Engine/tables?

Og is at 0.50, so about 50 revisions (actually I think more like 35
public ones..), not the version number '0.5'.

MySQL is (and always has been) actually the 'premier' DB used by the head
maintainer.   It's just always those weird other people like me who just
use PostgreSQL.  ;)  (Which means, that I optimize Og for my psql usage,
only run the specs with it etc, which means that sometimes the psql part
is better supported than the mysql/sqlite one).
In-memory SQLite is actually quite nicely supported, and I know one from
IRC who used it to speed up Og quite a bit (synchronizing the mem with
a real backend now and then).
I know nothing about MySQL memory engines, so can't comment.

Hope that helps,


Feel the love

More information about the Nitro-general mailing list