JOG wrote:
> dawn wrote:
>
>>JOG wrote:
>>
>>>dawn wrote:
>>>
>>>>Keith H Duggar wrote:
>>>>
>>>>>dawn wrote:
>>>>>
>>>>>>Walt wrote:
>>>>>>
>>>>>>>Many have attempted, but you have been expounding on the same incorrect
>>>>>>>ideas for something like five years now.
>>>>>>
>>>>>>Could you point me to proof that something I expound is incorrect?
>>>>>>Perhaps just starting by telling me what I think to be true that you
>>>>>>think false, or vice versa, would be helpful. I would very much
>>>>>>appreciate knowing.
>>>>>
>>>>>RM != SQL
>>>>>QED
>>>>>
>>>>>Keith -- Fraud 6
>>>>
>>>>Hi Keith - I do not equate RM with SQL. I do think, however, that we
>>>>would not have SQL were it not for the RM.
>>>>The RM could be seen as a primary "culprit" in giving us SQL.
>>>>Additionally, most, if not all, implementations that are based on the
>>>>relational model employ SQL as the means of interacting with the DBMS.
>>>>Marketing and other materials for a couple of decades now use the
>>>>acronym RDBMS when referring to SQL-DBMS's for good reason.
>>>>[snip]
>>>
>>>It is not that you confuse RM with SQL.
>>
>>Good, because I have heard that a number of times, and I did not think
>>it to be the case.
>>
>>
>>>It is that because RM doesn't
>>>do everything you want
>>
>>I don't even think of it as "doing" anything, but as "being" so that
>>might be a problem.
>>
>>
>>>(and only an idiot would think that the RM is
>>>the last word in data management),
>>
>>Agreed. For a couple of decades it dominated in the world of database
>>buzzwords, however. That is only starting to change (perhaps) very
>>recently.
>>
>>
>>>you promote throwing the baby out
>>>with the bath water,
>>
>>I can think of a few things I would throw out (the three I mentioned).
>
>
> This is RM != SQL again. You stated that only _one_ of the three was
> relevant to the modern view of RM, but you now want to throw out three
> - this is illogic.
>
>
>>I don't know if those are what you are calling "the baby"
>
>
> No pointers. No dependence on manual navigation. Thinking in terms of
> propositions not objects. Essentially the information principle. We
> must not lose the invaluable insights if we are progress to even better
> techniques.
>
>
>>or if it is
>>related to my questions (and not fully developed opinions) on typing,
>>metadata as data (related to DBMS constraints or lack thereof), or
>>additional functions, such as navigation, in addition to set-based
>>functions.
>
>
> Functions on datatypes are external to the underlying algebra. So again
> not part of the RM, and can be happily part of a DBMS.
>
>
>>I do not throw out relations nor functions on them, but I
>>do favor also talking about relations as functions, since I have rarely
>>(if ever) worked with relations that are not in data-based software
>>development.
>
>
> A db-tuple is mathematical function. A db-relation is a commonly
> structured set of these functions.
>
>
>>>and losing all of the invaluable insights that
>>>Codd brought.
>>
>>I definitely do not want to make the same mistake made by some who
>>started with the RM around '70 or thereafter and dumped the wealth of
>>best practices in data-based software development that preceeded it.
What a fucking idiot Dawn is. The best practices pre-1970 were shitty.
Codd convinced one user group struggling with the best way to deal with
"5 difficult problems in data management" by writing one-liners for each
of the 5 problems.
Dawn is a clueless git. I wish you would stop encouraging her.
Received on Sun Jan 21 2007 - 23:35:33 CST
