Re: Complicated query

From: Jerry Stuckle <jstucklex_at_attglobal.net>
Date: Fri, 12 Dec 2014 19:57:02 -0500
Message-ID: <m6g2sd$6t0$1_at_dont-email.me>


On 12/12/2014 7:29 PM, Denis McMahon wrote:
> On Fri, 12 Dec 2014 13:40:40 -0500, Jerry Stuckle wrote:
>

>> On 12/12/2014 12:04 PM, Peter H. Coffin wrote:

>
>>> Here is the DDL richard posted that you said you'd use.
>>>
>>> -----------
>>> Columns would be ID Question Achoice Bchoice Cchoice Dchoice Correct
>>> -----------
>>>
>>> One question, four answers, which one's correct.
>>>
>>> You are misremembering what you agreed to or you're misrepresenting it.
>>> Either way, Jerry's assessment of what richard posted is true.

>
>> Thank you, Peter!

>
> Having said all that, when I go back and look at the original posts,
> possibly due to the way in which the original question was posed,
> richard's solution is not a solution at all because he's not actually
> storing what he thinks he's storing.
>
> Consider the questions:
>
> q1:firstname?
> q2:lastname?
> q3:dateOfBirth?
> q4:homePhone?
> q5:workPhone?
> q6:maritalStatus?
>
> And now the list of answers is clearly a linked set of fields describing
> a person, and I don't think any of us would argue that the correct form
> for these "answers" is to be held in an answers table with a reference to
> a person id and a question id each.
>
> q1|0001|fred
> q1|0002|Jim
> q1|0003|Sarah
> q6|0003|Single
> q4|0002|1982-05-16
>
> etc .......
>
> but rather:
>
> 0001|fred|smith|1962-04-18|0123456789|07712345678|Married
>
> etc ........
>
> So I think a lot of the ensuing debate here may have been caused by
> richards complete and utter failure to understand the OPs actual
> situation and then propose a typically richardian solution to a totally
> different problem to that described by the op which the op, with no
> understanding of richardian thought processes and the richardian database
> design philosophy[1], has then mapped into their own perception of how
> the data ought to be defined.
>
> I could be wrong.
>
> [1] do random stuff and see if it works.
>

True, but I would argue one point. Phone should be a separate table with a type, i.e. Home, Work, Cell. Then a third table with phone_type_id and phone_type. That way you can add other types, also, such as fax.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex_at_attglobal.net
==================
Received on Sat Dec 13 2014 - 01:57:02 CET

Original text of this message