[stamp] Re: Database Variables
- From: Steven Buss <steven.buss@xxxxxxxxx>
- To: stamp@xxxxxxxxxxxxx
- Date: Wed, 1 Feb 2006 14:57:51 -0500
Alright, that's a good point, sounds good to me.
On 2/1/06, Brandon Ripley <Brandon.Ripley@xxxxxxxxxx> wrote:
>
> 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> 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> 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> 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> 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 > wrote:
> > > > > >
> > > > > > Thanks for the feedback, I made a couple comments below.
> > > > > >
> > > > > > ------------------------------
> > > > > > *From:* Erik Thulin [mailto:ethulin@xxxxxxxxx]
> > > > > > *Sent:* Tuesday, January 31, 2006 8:42 AM
> > > > > > *To:* 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> 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
> > > > > 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
> > > 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
> PHP/MySQL programmer
>
>
--
Steven Buss
steven.buss@xxxxxxxxx
PHP/MySQL programmer
Other related posts:
