Re: storing survey answers of different data types
Date: Sat, 25 Apr 2009 22:03:17 -0300
Message-ID: <49f3b2da$0$5478$9a566e8b_at_news.aliant.net>
Joe Thurbon wrote:
> On Sun, 26 Apr 2009 03:35:57 +1000, Bob Badour
> <bbadour_at_pei.sympatico.ca> wrote:
>
>> 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.
>
> [...]
>
>>> 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
>
>
> [...]
>
>>> 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). >> >> Impossible? It's a simple foreign key reference to the system catalog. >>
>
> This just seems to shift the issue to the system catalog. Doesn't the
> system catalog make assertions about which tables exists, but those
> assertions are not modelled as constraints?
>
> In other words, I think that the system catalog is a bit of a red
> herring. I had intended that the Questionnaire table in the example
> above take its place entirely.
The Questionnaire table in the example above says nothing about the columns of the tables.
>>> 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 have Cimode filtered so I have no idea what he posted. >> (Incidentally, I am a duplicate row in his fraud table.) >>
>
> Fair enough. I won't try to reiterate it here.
>
> [...]
>
>>>>> "What are all the answers to all of the questions to all of the >>>>> questionnaires?" >>>> >>>> The contents of the database. >>> >>> I don't think so. >> >> It is quite clearly and quite explicitly the answer to the question. >> If you think otherwise, I am at a loss.
>
> You snipped the second sentence in my reply. It said that (perhaps
> unclearly)
> (1) the Questionnaires table (or system catalog, or equivalent)
> is in the database, and must be there to list the questionnaires
> (2) the system catalog is not the answer to a question in a questionnaire,
> (3) 'the contents of the database' is therefore not the answer to the
> query,
> because it contains too much information.
I fail to see the point. The contents of the database are the answers to all the questionnaires regardless what else might be in there.
>>>>> Maybe my question (the one I didn't manage to ask upthread) >>>>> doesn't have a meaningful and consise answer. Maybe the question >>>>> is just "How to I design a schema that makes the right >>>>> tradeoffs for my requirements?" But there seems to be an issue >>>>> with the approach above, because it makes everything 2nd order, >>>>> and hence not expressible as relations. (How's that for an >>>>> assertion without proof?) >>>> >>>> Absurd. >>> >>> Which bit? >> >> The assertion without proof and the idea that a 1st order logic >> system is somehow magically 2nd order.
>
> I thought it was straightforward. I'll list my reasoning here,
>
> (1) Each relation R is a predicate
> (2) Each tuple in the relation R(v1, ..., vn) is a ground instance
> of that predicate
> (3) A system catalog is a predicate which contains unground instances
> of other predicates.
> (4) That's second order
3 is dodgy. A system catalog is just a bunch of relations a la 1) and 2).
> I think that the reasoning is sound, but am happy to be shown otherwise.
> I don't think I've entered a thread in comp.object without learning
> something.
I suggest you probably learned less than you thought. Received on Sun Apr 26 2009 - 03:03:17 CEST