[stamp] Re: Database Variables
- From: Brandon Ripley <Brandon.Ripley@xxxxxxxxxx>
- To: "'stamp@xxxxxxxxxxxxx'" <stamp@xxxxxxxxxxxxx>
- Date: Wed, 1 Feb 2006 12:56:55 -0600
Agreed. The calculation isn't that difficult (adding and subtracting a hand
full of numbers) and we will be doing a whole lot of other operations when
we generate the data output page anyway. I don't think this calculation is
going to be a significant adder in computation. Just keeping the number up
to date, doing that score summation every time the scouting data changed, is
going to be more of a pain because you need an extra select and update
statement loop.
I strongly feel that we should dump the alliance scouted score fields.
Brandon
_____
From: Ryan McElroy [mailto:ryan@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 01, 2006 12:10 PM
To: stamp@xxxxxxxxxxxxx
Subject: [stamp] Re: Database Variables
I am a bit of a database purist and would argue against storing purely
calculated values. However, as I am not implementing that part of the
system, I won't complain if you do. What I am curious about is what exactly
is the point of calculating ScoutedScore, ever? I mean, the whole point of
this app is combine the data scouted in many different forms, right? Maybe
I want to rank on average balls rolled per match, or on median balls shot
per
match, or on total points scored in all matches. And I'll want to calculate
this per-team, not per-alliance, right? Each of these requires the use of a
different set of inputs, so I don't see the use of having one set of those
inputs stored in the database. Of course, I might be missing something
still, so please fill me in if I am.
~Ryan
Steven Buss wrote:
So why not have the fields recalculated every time an edit is submitted? It
wouldn't be any different than calculating it when the data is displayed and
if a lot of people view the page it would save on processing time.
Of course, its not really that big of a deal, we can do it either way and I
won't complain. Just wanted to make a case for it :P
On 1/31/06, Erik Thulin <ethulin@xxxxxxxxx <mailto:ethulin@xxxxxxxxx> >
wrote:
Sure. So what that is is a sum of all the scored balls for the red alliance
minus the penalties for the red one, and a sum of all the scored balls for
the blue alliance minus the penalties. This may differ from the REAL match
score due to some one missing a ball etc. It is reliant on other fields and
is therefore calculable.
- Erik
On 1/31/06, Steven Buss < <mailto:steven.buss@xxxxxxxxx>
steven.buss@xxxxxxxxx> wrote:
I must not understand what is supposed to go into those fields then, can you
explain what data goes there to me?
On 1/31/06, Erik Thulin < ethulin@xxxxxxxxx <mailto:ethulin@xxxxxxxxx> >
wrote:
The reason we should not calculate it is if you were to edit the entered
scores later those would stay incorrect. Those other value names sound
good.
- Erik
On 1/31/06, Steven Buss <steven.buss@xxxxxxxxx
<mailto:steven.buss@xxxxxxxxx> > wrote:
I think we should keep the two fields "redScoutedScore" and
"blueScoutedScore," unless I misunderstand what they represent. The
database only changes when we post new data, so everytime new data is added,
the scores are recalulated. It will help with the speed of the application
to calc. everything beforehand. Its a speed-memory tradeoff, and its very
little memory.
I agree, matchSchedule and matchRobotData sounds good.
On 1/31/06, Brandon Ripley < Brandon.Ripley@xxxxxxxxxx
<mailto:Brandon.Ripley@xxxxxxxxxx> > wrote:
Thanks for the feedback, I made a couple comments below.
_____
From: Erik Thulin [mailto:ethulin@xxxxxxxxx <mailto:ethulin@xxxxxxxxx> ]
Sent: Tuesday, January 31, 2006 8:42 AM
To: stamp@xxxxxxxxxxxxx <mailto:stamp@xxxxxxxxxxxxx>
Subject: [stamp] Re: Database Variables
Well, you know my opinion on a lot of those rows in teamRobot are not
needed. If we do put them in we must make sure we finish the rest of the
app before we really do anything with them. I really don't have an issue
with them being there but the deviate from the mission of STAMP so I want to
devote our time to the other portions.
redScoutedScore
blueScoutedScore
^These are not needed, they can be calculated
Yes, these are redundant. Our initial thought was that the calculation to
figure out alliance scores would happen many times, every time the output
page is generate, so why not do the calculation once and store it.
Unfortunately, that brings up the issue of how do you coordinate an update
to the scouting data and when the tallied score is calculated. I agree,
these variables should be dumped.
I saw the "on ramp" value and that makes since, Ryan that should be added to
the match input page.
The only other things are the table names:
matchData
matchRoster
were a bit confusing to me. I would make "MatchRoster" into "match data"
seeing as that is the data specific to the match. I would then make the old
"matchData" "matchRobotData".
matchData seems a bit ambiguous, it could relate to any data about or from a
match, how about matchSchedule?
matchRobotData sounds good.
Good job guys,
- Erik
On 1/31/06, Jeremy Johnson <mias88@xxxxxxxxx <mailto:mias88@xxxxxxxxx> >
wrote:
Attached is a file with all the variables we plan to use. If you have
any questions, feel free to ask.
-Jeremy
--
Unless otherwise noted the content of this message is licensed under a:
Creative Commons Attribution, Share Alike License. CreativeCommons.org
Blog: http://www.freedomdown.net/blog/ <http://www.freedomdown.net/blog/>
--
Steven Buss
steven.buss@xxxxxxxxx <mailto:steven.buss@xxxxxxxxx>
PHP/MySQL programmer
--
Unless otherwise noted the content of this message is licensed under a:
Creative Commons Attribution, Share Alike License. CreativeCommons.org
Blog: http://www.freedomdown.net/blog/ <http://www.freedomdown.net/blog/>
--
Steven Buss
steven.buss@xxxxxxxxx <mailto:steven.buss@xxxxxxxxx>
PHP/MySQL programmer
--
Unless otherwise noted the content of this message is licensed under a:
Creative Commons Attribution, Share Alike License. CreativeCommons.org
Blog: http://www.freedomdown.net/blog/ <http://www.freedomdown.net/blog/>
--
Steven Buss
steven.buss@xxxxxxxxx <mailto:steven.buss@xxxxxxxxx>
PHP/MySQL programmer
Other related posts:
