[stamp] Re: Database Variables
- From: Ryan McElroy <ryan@xxxxxxxxxxxxxxxxx>
- To: stamp@xxxxxxxxxxxxx
- Date: Thu, 2 Feb 2006 00:16:04 -0800
Ramp input now exists... XHTML 1.1 compliant... Anyone gifted with
JavaScript want to write a form validator to prevent submitting incomplete
forms (such as when a user accidentally hits enter)? If not, I can get
something working but I don't promise anything pretty.
Also, check out:
<http://trc.silverfir.net/scouting/2006/six_teams.php>
versus
<http://trc.silverfir.net/scouting/2006/six_teams.php?min>
The latter is a "minimized" version without the +/- links... I actually like
it better, myself, because the user can tab through each field much more
quickly... Its better for massive data entry that way, but maybe worse for
real-time data entry. Both options are available, of course.
~Ryan
On 2/1/06, Steven Buss <steven.buss@xxxxxxxxx> wrote:
>
> 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:
