Re: storing survey answers of different data types
Date: Sat, 25 Apr 2009 16:43:25 GMT
Message-ID: <N4HIl.24218$Db2.13244_at_edtnps83>
Joe Thurbon wrote:
> On Sat, 25 Apr 2009 10:57:16 +1000, Bob Badour
> <bbadour_at_pei.sympatico.ca> wrote:
>
>> Joe Thurbon wrote: >> >>> On Fri, 24 Apr 2009 14:41:12 +1000, Bob Badour >>> <bbadour_at_pei.sympatico.ca> wrote: >>> >>>> paul c wrote: >>>> >>>>> Bob Badour wrote: >>>>> >>>>>> paul c wrote: >>>>>> >>>>>>> Bob Badour wrote: >>>>>>> >>>>>>>> Joe Thurbon wrote: >>>>>>> >>>>>>> >>>>>>> ... >>>>>>> >>>>>>>>> Just wondering, if one of the requirements for a system included >>>>>>>>> something like 'Be able to list all questionnaires', would >>>>>>>>> you still consider one-table-per-questionairre a reasonable >>>>>>>>> design? >>>>>>>> >>>>>>>> >>>>>>>> Absolutely. It's a simple query from the system catalog. >>>>>>>> ... >>>>>>> >>>>>>> >>>>>>> How do you tell the 'questionnaire' tables from the other tables? >>>>>> >>>>>> >>>>>> However you want. >>>>> >>>>> Well, it's not me, the part-time mystic, I'd like to know how a >>>>> system catalog/catalogue can signify the difference. >>>> >>>> >>>> Why does the system catalog have to signify the difference? One can >>>> create any relation one wants to identify them. >>>> >>>> >>> My problem with the approach is that, even if you have a way to >>> identify the correct tables, it's still inconvenient to manipulate >>> them. >>> For example, given >>> Catalog(TableName, IsAQuestionnaireTable) >>> QTable1(...) >>> QTable2(...) >>> ... >>> there is an implicit constraint that Catalog.TableName refers to >>> tables that exist in the database, and another that if >>> IsAQuestionnaireTable is true, that that table is a table that >>> represents answers to a questionnaire. This is not encoded anywhere, >>> and I don't think it can be encoded anywhere. >> >> 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.
> ...
Cimode accomplishes that by guaranteeing that all relation headings to do with surveys are known in advance, ie., without needing to query the catalog. In his version, the catalog need have nothing to do with such requirements, 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 . 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.
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. 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'. Received on Sat Apr 25 2009 - 18:43:25 CEST