Container for Multiple Choice Quizes

[Kay C Lan]

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