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 <ka...@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 <a...@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution