Container for Multiple Choice Quizes
stephenREVOLUTION2 at barncard.com
Wed Oct 28 14:24:16 CDT 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
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
>>> quiz/questions/answers. Changes would be pretty obvious
>>> -- Alex.
>>> 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
>> 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
>> files (spreadsheet style again) which you feed into Rev to build your own
>> You say you like to keep it Rev + plain English and no 'service agents',
>> 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
>> + files.
>> I agree that for only 2000 records a db is a bit of an overkill, but by
>> same token, 'for me personally', I find it much easier to get my head
>> the relationship of a bunch of flat files where a DB does all the leg
>> 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 &&
>> 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
>> 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
>> = "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
>> 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
>> 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
>> table is 54MB when exported as a tab delimited text file. It takes less
>> 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
>> 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.
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode