Container for Multiple Choice Quizes

stephen barncard stephenREVOLUTION2 at barncard.com
Wed Oct 28 15:24:16 EDT 2009


A client-server database is just a really organized place to put stuff, not
that big a deal, especially with Rev. I came to that realization when I saw
some php code that used a mySQL table with just one record with one field of
data.
-------------------------
Stephen Barncard
San Francisco
http://houseofcubes.com/disco.irev


2009/10/28 Sivakatirswami <katir at hindu.org>

> 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
>>
>>
>>
> _______________________________________________
> 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
>



More information about the use-livecode mailing list