Re: storing survey answers of different data types
Date: Sat, 25 Apr 2009 23:41:59 GMT
Message-ID: <op.usyur90xq7k8pw_at_imac.local>
On Sun, 26 Apr 2009 02:43:25 +1000, paul c <toledobythesea_at_oohay.ac> wrote:
> Joe Thurbon wrote:
[...]
>>> >>> I cannot make sense of the above. >>> >> Sorry, I'll try again. >> Take a table called "Questionnaires", with a single column, called >> "TableName". >> For example, the table Questionnaires might contain >> Questonnaires TableName >> =============------------------- >> Customer Survey >> Staff Satisfaction Survey >> meaning that there are two questionnaires. >> So, there will also be two tables, one called "Customer Survery" and >> one called "Staff satisfaction survey". Each table contains the answers >> to the questions in the respective questionnaire. >> Customer Survey A1 A2 A3..... >> ===============--------------------------- >> and >> Staff Satisfaction Survey Aa Ab Ac >> =========================--------------------- >> My point above is that is it impossible to encode the constraint that >> the values in the Questionnaires table correspond to tables, and that >> those tables must exist in the database. (Actually, it's more my >> contention than my point - I'm not actually sure that it's true). >> With other approaches (cf Cimodes example in this thread), that >> constraint is made clear, at the expense of having a significantly more >> complicated schema. >> I'm not really interested in which approach is better, just trying to >> understand the strengths and weaknesses of each. >> ... >
> I'd say that Cimode's scheme anticipates requirements such as being able
> to answer questions like "what questions are common to all surveys?', as
> well as your question and mine.
>
Absolutely.
>
> Cimode accomplishes that by guaranteeing that all relation headings to
> do with surveys are known in advance, ie., without needing to query the
> catalog.
Yep.
> In his version, the catalog need have nothing to do with such
> requirements,
Yep.
> assuming we are not talking about what Codd called a 'dictionary'.
> If I read your example right, for a 'catalog' to be involved, a system
> would need what I think of as an 'indirection' operator that would have
> the effect of being able to be based on an algebra that could 'switch
> gears' by differentiating the things it deals with from the names or
> labels of the things it deals with .
That what I was intending, so I think you've read my example right.
> It does sound like 'second order' to me. I've seen systems that had
> such operators but those weren't exactly what Codd prescribed as
> relational but maybe more importantly, they required users to write
> loops.
>
Such loops are, no doubt, found in the constraint checker in a DBMS.
>
> As Date points out somewhere, In the 1969 paper Codd talked of
> second-order but in the 1970 paper he said first-order was sufficient.
> That seems to agree with Cimode's version.
I think so, too.
> My attitude is that you can always get what you want if you have enough
> attributes, which in this case lets you avoid the 'catalog'.
Agreed. The cost may be in the complexity of the resultant schema.
It occurs to me that Cimode's approach allows you to use a DBMS's referential integrity checking, but that if you want to make requirements that questions have particular types of answers that you are expecting, you have to roll your own type system. The 1-table-1-questionnaire allows you to use a DBMS's type system, but if you want to do querying, you have to roll your own query engine (the 'loops' you referred to above).
(This opinion may be revised when I work out why I can't understand Bob's assertions elsethread - I'm working on that).
Cheers,
Joe
Received on Sun Apr 26 2009 - 01:41:59 CEST