Container for Multiple Choice Quizes

[Sivakatirswami]

Thank you, Kay

All good thoughts. In all likelihood the concept will progress to 
requiring some user tracking and "levels" tracking and  thus, inevitably 
a dbase may serve better.

The other way to go is have a stack on the webserver as my dBase.

Kay C Lan wrote:
> On Wed, Oct 28, 2009 at 8:31 AM, Alex Tweedly <alex at tweedly.net> wrote:
>
>   
>> Answer (b)
>> instead of a subfolder, I might have a Tab separated "spreadsheet" with the
>> quiz/questions/answers. Changes would be pretty obvious
>>
>> -- Alex.
>>
>> Sivakatirswami,
>>
>> I'd have to agree with Alex's option b. There's nothing that you
>>     
> 'currently' propose that suggests relational db or arrays to me.  A simple
> flat tab delimited file as suggested seems simple enough.
>
> Depending on where you're headed I might suggest a db solution.
>
> Firstly may I suggest that you consider two extra columns, level and
> dateTime (the seconds). Depending on your intended audience, having the
> ability to choose, Easy, Medium or Hard questions may be appropriate. Also
> knowing when the question was last attempted can prevent the same old
> questions being asked time and time again.
>
> Which then leads me to the possibility of a db solution. If you are going to
> track individual performance against your quiz then you are going to need
> some sort of relational tracking system, whether it be a db or multiple flat
> files (spreadsheet style again) which you feed into Rev to build your own
> array.
>
> You say you like to keep it Rev + plain English and no 'service agents', but
> if you are headed for the web, then you're really talking Rev + Internet
> Library + files, which isn't really too much different than Rev + DB Library
> + files.
>
> I agree that for only 2000 records a db is a bit of an overkill, but by the
> same token, 'for me personally', I find it much easier to get my head around
> the relationship of a bunch of flat files where a DB does all the leg work,
> than trying to build and manage Rev Arrays - not that Rev arrays are hard,
> or that I don't use them, it's just that for me in many cases a DB does it
> quicker and for Arrays it can turn very complex and convoluted very fast -
> for this old brain.
>
> One of the first things I do when I create a new Rev + db is add a
> button/menu item that does a:
>
>  revExecuteSQL databaseID,"SELECT * INTO OUTFILE" && defaultFolder && "FROM
> dbTable"
>
> which simply creates a tab delimited plain flat file of the entire table -
> if you have multiple tables put it in a repeat loop and create a file for
> each table. To me there is very little difference between looking at these
> files in Numbers/Excel or just viewing the DB table in Navicat Lite.
>
> You, I and most people can look at a flat file full of info and go, well I'm
> only interested in this line, and that line and .... You could feed that
> file into Rev and do a couple of 'filters' and achieve the same, but I
> reckon a simple
>
> revQueryDatabase(dbID,"SELECT * FROM Quiz WHERE level = 'Hard' AND category
> = "Biology")
>
> will be faster to type and yield the results faster.
>
> For what you are intending, I don't see the SQL commands being any more
> demanding to learn than anything in Rev - in Rev 'filter' you know * is a
> wildcard character for ALL so nothing new there.
>
> revMoveToNextRecord recordSetID
>
> is pretty simple as far as navigation is concerned, and as the data comes in
> as a simple one line* list it is pretty simple to figure out which item of
> the list goes into which fields for display.
>
> *One big gotcha is if any of you data contains commas, tabs or returns it
> can play havoc when pushing/pulling records from a db, but the same is true
> with arrays using split and combine.
>
> SQL can seem daunting, but what you are currently proposing is on the EASY
> end of the scale, the syntax as easy as Rev. In a Quiz db I run the largest
> table is 54MB when exported as a tab delimited text file. It takes less than
> a second for Rev to tell mySQL to have OS X produce the file.
>
> So I'd at least give it a go. You never know, once you have that AHA moment
> with SQL you might consider a relational variation where you do track
> individual performance, and that is where I see the true benefit of a DB.
> The more features and size you add the more it becomes suited to a db.
>
> HTH
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>