Re: storing survey answers of different data types

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.

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

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

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.

Cheers,
Joe Received on Sun Apr 26 2009 - 02:41:37 CEST