[Rails] Re: Re: Re: Rails without a primary key

Michael Artz mlartz at gmail.com
Sun Jul 30 02:20:01 GMT 2006


> > I think the idea is that no access to the table will result in a
> > single row being returned so there is no reason, practical or logical,
> > to have a key on this table.
>
> I guess it depends on your usage of this data. If it's reporting, fine.
> If you have to update row #1907135067, having a unique ID is what works
> best with an ORM solution.

Yep, reporting.  My DB is a read-only data warehouse, which I guess
would be considered an "integration" database from Rails' perspective.

> > ..... I have
> > similar (legacy) projects generating 200-300GB per day of traffic, so
> > every bit that we can save per record results in a fairly large
> > savings overall.
>
> What is your memory footprint when loading all these records? In all the
> ORM projects I've been on, memory usage became an issue when the tables
> were large. This is because a unique object is created for each row, and
> if you load 2 million rows you have 2 million objects in memory. This is
> another case where ORM is not the best way to go.

I don't load all the records into the interface ... that would be
crazy :)  I just need to be able to put a quick query interface onto
the database so that an analyst can issue queries and anything that
would be too unwieldy for AR is probably too unwieldy for a normal
analyst :)

> > Rails has been a quick way to put a face on those databases and it
> > works great for simple models or those that conform to Rails
> > conventions.  That composite key plugin looks mighty useful, however.
>
> I'd love to find out your experience with that plugin, as
> legacy/enterprise integration is key to being able to use Rails at work
> for many Java/DotNet developers.

I'll keep you posted, once I have a chance to get to it.


More information about the Rails mailing list