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* < steven.buss@xxxxxxxxx <mailto: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/
-- 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/
-- 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/
--
Steven Buss
steven.buss@xxxxxxxxx <mailto:steven.buss@xxxxxxxxx>
PHP/MySQL programmer
