refactoring models

Perhaps you could explain in more detail what you mean. Give an
example of the comparison you are trying to make.

Colin

Are you asking whether a class derived from ActiveRecord::Base uses
more resources than one not so derived, apart from the resources used
by ActiveRecord::Base? Sorry that seems to me to be not a useful
question to ask. As I said previously if you could give some
background as to why you are asking the question it may make more
sense to me.

Colin

Please quote the previous message and insert your comments at the
appropriate points. It makes it easier to follow the thread. Thanks.

OK from my first post. I am refactoring trying to make my app lean and
agile. The less models loaded up the less memory obviously.

Not necessarily. In terms of resources just loading models I would
think it is more down to lines of code than number of models.

I was curious
if refactored out the DB portion and left the ruby model if it would have a
noticeable impact

Perhaps I am being particularly dense today, again I do not understand
what you mean by refactoring out the db portion and leaving the Ruby
model.

or whether getting rid of the model and refactor into
another on needed is a better way to lean the app.

Do you mean combining non-AR models or what?

Colin

To repeat, please quote the message you are replying to. Thanks

not sure what else to say. If you have a db table with 2 lines that are
never going to change. You refactor that into the other model that
references it and remove the original AR model. I was wondering, when you
remove the table if you were to keep the original model but refactor the
stuf into that mode instead of the referring model does it consume the same
memory, BW, whatever, as opposed to the AR version of the model.

A key fact missing previously was that you have a very small table and
could just hard code the data.
The answer is who cares? Don't worry about it unless you have
performance or resource problems, in which case profile the code to
find out where the problem lies and then address it. I can virtually
guarantee that the bottlenecks or resource hogs will not be in the
areas you might anticipate beforehand.

Colin

I would think that a select box populated by an array or hash is MUCH faster and less system intensive than doing any db lookup.

It probably is, but why were you putting the data into a database? If there's a valid reason to do that, do it and then fix db performance with caching if it becomes a limiting factor.

If there's not a valid reason to put the data into a database, why would you do so? Start with the simplest thing that would possibly work to get your tests passing and go from there.

There was some discourse on one of the agile-like lists (maybe the XP list) recently with some people suggesting you shouldn't actually add support for a db to an app until you have the first test that won't pass simply by using in memory representations. That's a little extreme for me, but certainly I wouldn't put stuff into a db unless there was a good reason. And if there is a good reason for it being there, I wouldn't remove it for performance reasons until I had failing performance tests and profiling that pointed to that query as being part of my problem.

Google "premature optimization"

Best Wishes,
Peter

Peter Bell wrote in post #974422:

It probably is, but why were you putting the data into a database? If
there's a valid reason to do that, do it and then fix db performance
with caching if it becomes a limiting factor.

If there's not a valid reason to put the data into a database, why would
you do so? Start with the simplest thing that would possibly work to get
your tests passing and go from there.

[...]

With Rails, sometimes using a DB is the simplest thing, and it's
actually harder not to do so. But I agree with the sentiment.

Best,

Maybe so but you do not have to 3rd level normalize EVERY thing in a db. I learned to normalize your tables. BUT, now if you have only several items that are fixed that are not going to change it is beter to NOT put it in the db if you are not going to change it or need it to create an interface to manage it.

Please quote when replying.

Chris Habgood wrote in post #974782:

Maybe so but you do not have to 3rd level normalize EVERY thing in a db.

Yes, you absolutely *do* have to normalize at least to 3NF. The only
excuse for a denormalized schema is if you've actually *measured* that
you've got a performance bottleneck that denormalization will solve
(note: in 11 years of Web application development, I've never once had
to do this).

I
learned to normalize your tables. BUT, now if you have only several
items
that are fixed that are not going to change it is beter to NOT put it in
the
db if you are not going to change it or need it to create an interface
to
manage it.

Often true. But that's a separate issue.

Best,

Please quote when replying.

Chris Habgood wrote in post #974782:

Maybe so but you do not have to 3rd level normalize EVERY thing in a db.

Yes, you absolutely *do* have to normalize at least to 3NF. The only
excuse for a denormalized schema is if you've actually *measured* that
you've got a performance bottleneck that denormalization will solve
(note: in 11 years of Web application development, I've never once had
to do this).

i think 11 years create u too old school... 3fn in web development? our dude, so if u like problems -))
if u use rails, ar- pattern, thinkin in models, not in database schema. + counter_caches columns (helpfull in development)

Ivan Nastyukhin wrote in post #974793:

Please quote when replying.

Chris Habgood wrote in post #974782:

Maybe so but you do not have to 3rd level normalize EVERY thing in a db.

Yes, you absolutely *do* have to normalize at least to 3NF. The only
excuse for a denormalized schema is if you've actually *measured* that
you've got a performance bottleneck that denormalization will solve
(note: in 11 years of Web application development, I've never once had
to do this).

i think 11 years create u too old school...

And I think you don't know what you're talking about.

3fn in web development? our
dude, so if u like problems -))

3NF *solves* problems. What problems do you think it creates?

if u use rails, ar- pattern, thinkin in models, not in database schema.
+ counter_caches columns (helpfull in development)

No! When working with SQL databases, you have to understand and work
*with* the database. When working with objects, you have to understand
and work *with* the objects. Fortunately, AR lets you do both
simultaneously if you know what you're doing.

And counter_cache should be considered a cheap performance hack, nothing
more. It's not necessary from a design standpoint if your data model is
correct.

Best,