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

Let’s say I have a model Poll which would have multiple Options. For
each Option a User can vote.

Let’s say in my particular case, certain Options are recurring. To save
database space, recurring Options such as “Yes” or “No” or “Maybe” are
stored once and then joined accordingly to relevant Polls… This makes
a HABTM setup better than a has_many setup (or at least I think it does)
so:

Poll < ActiveRecord::Base
has_and_belongs_to_many :options
end

Option < ActiveRecord::Base
has_and_belongs_to_many :polls
has_many :votes
end

Vote < ActiveRecord::Base
belongs_to :option
belongs_to :user
end

The problem with this setup is that a Vote belongs to an Option, but in
respect to a specific Poll. If I just were to count the total number of
Votes for an Option normally - like @option.votes, then the total would
be for all Polls combined. But I need it to be specific to the one Poll
and can’t quite figure out the design pattern I should be using.

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!

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

I’m just a kid trying to figure something out for learning purposes and
to better my app. To be honest, I value that more than the monetary
aspects of development. If I had to meet deadline then I might say
“screw it” and do it as best I know how, but while I’m still learning
Rails, wouldn’t it be better to take my time and learn?

I’m just saying, perhaps my approach is wrong, but you picked it apart
on a capitalistic aspect instead of actual design.

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,
Bill

just an idea:

#in your controller

Poll has_many options, options has_many votes, so just do a find

with a nested include
@poll.find :first, :conditions => [‘id = ?’,params[:id]], :include =>
{ :options => :votes }

in your view

    <? @poll.options.each do |o| ?>
  • <?= "#{o.text} (#{o.votes.count} votes)"
  • <? end ?>

The thing is, I look at my situation as a difficulty based on my skill
level with Rails. I was asking “is it possible?” and, “if so, how
difficult is it?”

If what I was asking required me to write a new module or cost me more
than, say, fifteen lines of code, then I would be against it.

My question was in part asking this. Is this attainable easily based on
what the framework already provides, or would it require a great deal of
extra work? I don’t regard asking the question as actual work or wasted
time. After all, this is my own personal project. Nothing is on the
line here; I’m still in the learning phase. One of the reason I’m
asking is for the knowledge, I’m looking at it from a design aspect. It
would be great to know how to do what I’m asking, if it’s even
feasible. Who knows, perhaps as I modify my app or add extra functions,
it might become totally necessary, and I’d be asking the same question
down the line. If not in this app, maybe the next? There’s nothing
wrong in knowing.

You bring up personal productivity over machine productivity. This is
part of the equation. If I can learn as much as possible now – the
why’s and why-not’s - then it will help me in the future when and if I’m
actually doing this kind of work for money. If, in the future, I can
have my stuff optimized and be just as productive in the process, then
I’m just that much better than those who never felt it necessary to
learn one way or the other.

But overall I feel that there needs to be a compromise between personal
productivity and machine productivity. You concentrate too much on
personal productivity and you can easily end up with crap-that-works;
like slapping together a term paper the morning before it’s due. You
concentrate too much on functional perfection and

But I didn’t get that answer from you, it was more like, “who cares?”

It didn’t really offend me but it did come off as kind of snippy.

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?

Absolutely.

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,
Bill

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.
-Nathan