> HTML for the checkbox, radio buttons and select options
> directly in the database without CF having to parse the
> information. ( I think this is possible within Oracle 9i as
> well-- the commands and techniques are different)
You can certainly do this, but all I can say is "Yikes!" Following this
logic to its extreme, why do anything in CF? Why not just put all of your
application logic in the database?
The answer, of course, is that doing this limits the maintainability and
reusability of your application. The presentation logic and the data access
logic are all mixed into one big pile this way, and if any part of it needs
to be changed, it'll affect everything else.
> Quiz display
> For displaying answers for each question the NON-XML method
> would involve running two querries-- one against a reporting
> database and the other against the question list. CF would
> then compare the results to see if we need to merge the two
> items. Even if we were doing one question at a time and
> saving the question number, as in a pool of question, this
> would still involve querrying the entire database every time
> (or be a drain on resources of a lot of people were using Q
> of Q functionality to do the same).
You can certainly amalgamate questions and answers into a single query, if
you want to do that and if it makes sense to do that. However, it may not
make sense to do that in any case.
While it's true that, all other things being equal, one database query
performs better than two, all other things aren't usually equal.
> Inserting answers into the reporting database
> Inserts work in the same way-- by placing the data into a
> table datatype one can quickly move information into the
> database (obv.. you'll place the the document into the proper
> format by turing the results into XML), into the right fields
> 20 questions at a time-- this way the database does not have
> to process 20 insert questions at a time -- less chance of a
> deadlock if you have quite a number of customers on the site.
I seriously doubt that this'll decrease the likelihood of a deadlock.
Instead of having lots of individual inserts, you'll have more lengthy
insert processes, and may increase the likelihood of a deadlock. But in a
well constructed relational database schema, you shouldn't have much chance
of a deadlock anyway, since one user's inserted answers shouldn't touch the
same rows as another's.
I've worked on several survey applications with all the requirements you've
stated (and more), but I've never found the need to use the database this
way to make them work well.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
