Re: storing survey answers of different data types

On Sun, 26 Apr 2009 11:03:17 +1000, Bob Badour <bbadour_at_pei.sympatico.ca> wrote:

> 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.
>

Given that my point was unrelated to the columns of the tables, I see that as a positive.

[...]
>>
>>>>>> "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.
>

So 'the contents of the database' as an answer is complete, but unsound?

>
>>>>>> 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).
>

Are you saying that none of the values in the system catalog are predicates?

>
>> 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.

Of course, it's possible.

Cheers,
Joe Received on Sun Apr 26 2009 - 03:47:43 CEST