Question I don't know how to summarize for the subject field

R Mason wrote:

This would be way easier if I just used has_many,
but then stuff like "Yes" or "No" would be in the
options table like a bajillion times.
Maybe my approach is wrong. Let me know!

IMHO, and with all due respect, your approach is dead wrong. Why are you concerned with optimizing the cost of something that is, for all intents and purposes, free? Storage costs are < $.01/MB. And you're going to sweat a couple of bytes? Oh yeah. "But $.01 times millions of users ..." So let's see. You're spending how much time, at how much per hour, figuring out how to save how much?

Normally I'd say "do the math". In a case like this, the math costs more than any answer will ever yield. Maximize human productivity. Machines are cheap.

Just my $.02.

Best regards,

Hi R,

R Mason wrote:

So should one abandon all attempts at optimization
merely because it takes more time than writing
sloppier, less-well-thought-out code?

'Sloppy' is not the converse of 'optimized'. IME, the converse of 'optimized' is typically 'readable, testable, easily maintained, ...'

... while I'm still learning Rails, wouldn't it be
better to take my time and learn?


Perhaps it was just my reading of the query. Here are the two things in your post that jumped out at me:

To save database space,
This would be way easier if I just

I'm just saying, perhaps my approach is wrong,

Rereading your original post in light of what you've said here, I see we're using 'approach' to mean two different things. Based on my reading of your post, I took you to mean 'optimize early' vs. 'only optimize when it solves an _existing_ problem.'

but you picked it apart on a capitalistic aspect
instead of actual design.

Perhaps it's not intuitively obvious, but Rails is fundamentally about personal, not machine, productivity. If it weren't, we wouldn't have Rails' very readable 'Actor.find_by_role_and_location_and_skills(...)'. We'd be writing raw SQL because 'it uses fewer cycles'. We wouldn't have ActiveRecord because 'meaningless id's waste space'. In fact, we wouldn't even have Ruby, since interpreted languages are inherently less efficient users of machine resources. Productivity is an Economic, not a Computer Science, concept. That's why my response focused on the 'capitalistic aspect'.

Having said that, I'm sorry my response offended you. Welcome to the community and good luck!

Best regards,

Even if it did come across badly to you, he was making a very good point. Ok, at the moment, $/hour isn’t an issue for you (it’s not for me, either), but if you’re planning on making a career out of this sort of stuff, now’s the time to get into ‘good’ habits. Basically, when it comes to optimisation, forget it. There are a very small number of people on this list who are able and willing to optimise effectively… for a two very good reasons. 1) It’s very difficult and 2) it usually costs more to optimise than to “waste” resources, and there are experts who devote themselves almost entirely to knowing when to optimise and when to just leave it as it is.

Hope this has helped.