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,
