[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