Re: Question on Structuring Product Attributes

Eric

> On Tuesday, 1 October 2013 06:41:41 UTC+10, Eric wrote:

> > On 2013-09-30, Derek Asirvadem <derek.asirvadem_at_gmail.com> wrote:

> James said that SQL was intended to be a language for deriving logical
> inferences.
> Rob said that saying this required "great poetic license".
> I suggested that there is evidence to the contrary.
> Where is the absurdity?

Too much simplistic black-or-white thinking. Or the rule-disproved-by-the-exception "logic". Both forms of "logic" are a few sandwiches short of picnic.

> > Rob's point (as I see it) is that the asylum dwellers rewrite history,
> > as they often do. Charging either the System R team, or the Sequel Team,
> > or the SQL Committee (of old, before they were subverted), with having
> > missing something that is relevant today, which was not a criterion in
> > the 1970's, is simply dishonest.

> You are making this up (and most of the rest of it) to support your own
> rather strange viewpoint.

https://groups.google.com/d/msg/comp.databases.theory/Gphu01jz4H0/QZi0EXbrhYoJ

"Database technology has come a long way since the 1970s when SQL was initially specified, and relational DBMSs do alot more than report-writing. But to suggest that in the 1970s, the authors were interested in "logical inference" requires great poetic license compared to "replacing the report-writer capabilities of IMS", and feels like history rewritten."

Evidently you missed Rob's post. But you argue anyway.

> > Those who demand that the physical implementation must be limited to
> > the limitations of the abstract, are lunatics.
>
> The physical layer can do whatever the hell it likes, as long as it can
> produce correct results efficiently enough. However it is supposed to
> have an interface limited to the abstract model being supported (in this
> case, Relational Theory). There are two levels here, and those who
> cannot distinguish them are very wrong. This does not imply lunacy.
> Unfortunately you seem to be one of those who fails to make the
> distinction.

Well, that sounds like a disagreement, not that either [one or the other] is *proved* "right" or "wrong". And the proof for the latter is not going to happen in this medium.

The people who have laboured over that entire issue for the last forty years will appreciate that. Those who have decided that that limitation is a stupid limitation, and have dispensed with it, have created reliable platforms. Those who think as you do (seduced by the "books" by "academics" and "mathematicians", no doubt), are still writing, their platforms are unfinished, and a labour to use. Visit HeyPrestoTheThirdManifesto for a veritable orgy of that kind of insanity.

Another way of stating that is this. Lunatics cannot abide us *not* submitting to their absolute demands on our thinking. They want us to be like them, to think like a lunatic, otherwise it scares the bejeezus out of them. That is why they should be locked up, they infect humans. If a human can, then there is nothing wrong with a physical layer that is not completely limited to the abstract layer, that goes beyond it. Of course, it can't be allowed to break rules that are defined in the abstract layer, that is a different thing, constraints, as opposed to limitations.

> There are two levels here, and those who
> cannot distinguish them are very wrong.

??? Please read the words again.

> > But 30 years after the null problem was resolved, ...
> So tell me, in as few sentences as possible, what *you* think the Null
> Problem is.

I don't have one. I can't define what I do not have. I have implemented close to eighty full databases in 34 years that do not have it, and any code written, even after I left will not have it.

Sybase and DB2 do not have one. In their default state of operation, Sybase and DB2 execute without the Null Problem. There is a configuration parameter ANSI_NULL, and the default setting is OFF.

For those who are addicted to problems that do not exist, who wish to create unpredictability and insanity where there is none, they are free to set ANSI_NULL to ON. I strongly recommend that you do not buy their wares.

Most of the people in the Sybase and DB2 world have not been contaminated with the Null Problem, the result is their databases and code work, at least predictably, but they may have difficulties handling Nulls stored in the database.

Those who have tertiary qualifications in it, before the education system was subverted, do not store Nulls in the database. Therefore, using Sybase and DB2 in their default operation, they do not have the Null Problem or the consequences. Therefore there are thousands of full database implementations out there that do not have it (and thousands of full database implementations out there that *do* have it).

And for the world outside the Sybase/DB2 world, who are in general far less educated, millions of full database implementations out there that *do* have it.

As far as the developers are concerned, along with my Standards for Transactions; OLTP; SQL coding; etc; etc, I give them instructions on: a. what is stored in the database
b. how to handle all data conditions, expected and unexpected I purposely do not inform them re the Null Problem, because it is an insanity, and I do not wish to inflict it on minds that are not (thus far, I hired them) insane. Their code, written against my database, never has the Null Problem, or the consequences of it.

(I have written about it scores of times, please google. IIRC there is a loooong thread somewhere here with a self-styled "academic" about the virtues of 3VL, multi-VL and braised VL. If you are genuinely interested in having the alien problem removed from your mind, as opposed to merely arguing about how everyone should have the disease, please open a new thread and email me.)

> While you are at it, tell me what Oracle "features" show that it can "do
> the Null Problem Really Well".

Oracle does not handle the empty set or the unknown value consistently. While not being SQL Compliant in many areas, in this one area, the cretin has implemented the Null Problem exactly as the insane SQL Committee have stated it. It is fair enough that the SQL Committee is clueless re the needs of a programming language (data sublanguage, yes), but it is a different thing altogether, to take that crap and implement it, because it leaves the implementation (platform) completely vulnerable and unpredictable. It may well be standard-compliant in the ANSI/IEC/ISO SQL arena, but the standard (in this one aspect) is stupefying, and more important, it is a breach other standards: human sanity; completion in a programming language; etc.

The capable human evaluates the contradicting standards, assigns an order to them, and produces a integral result. Others do something else.

Answer: each and every Oracle command returns different values, and handles the Null Problem differently. Refer to the manuals for a list.

> And finally, people can disagree with you, and even be wrong in doing
> so, without being lunatics, or insane, or abnormal.

Apologies. See my post to Jan. I was addressing the behaviour, which specifically was insane "thinking" or "logic" (ie. devoid of thinking or logic). Not the person.

I do not post much here. It is fair enough that due to the subversive books, people who do not browse c.d.t are tricked into subverting their databases, thinking that some insane garbage is the Relational Model, but I am surprised that people here are so tricked.

Cheers
Derek Received on Tue Feb 25 2014 - 10:34:37 CET