Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
SQL Bashing - the Sport of Champions!
119 views
Skip to first unread message
Derek Asirvadem
Feb 18, 2015, 4:51:41 AM2/18/15
to
James
> On Thursday, 12 February 2015 17:23:44 UTC+11, James K. Lowden wrote:
> > On Tue, 10 Feb 2015 23:06:25 -0800 (PST) Derek Asirvadem <derek.a...@gmail.com> wrote:
> > Thank you for your excellent post. I will get to the rest on the weekend
Now in that otherwise excellent post and ongoing discussion, I had stated:
>>>>
I am aware that the Dates and the Darwens of the world propagate a myth, that SQL is broken, and that you can't do this or that. Let me assure you that the myth is false, self-serving. There is nothing in it. In my three years at the TTM encampment, every so often, either one of the slaves or the slave master himself would post a "here is something SQL cannot do, here is proof that SQL is broken" article. In every instance, I posted a full solution using SQL (nothing but SQL), and proved such to be false.
I am quite willing to do that here. Please give me an example of what SQL cannot do. Re RDBs.
<<<<
Evidently, the mere sight of the words:
> > ... SQL cannot do ...
caused you to entirely forget the context of the thread (Normalisation, the abject failure of theoreticians to Normalise anything) and the post, and to embark on the sport that is dearly beloved of theoreticians: SQL Bashing.
I was treating the difficulties that you were experiencing with SQL as a serious business, and I was offering assistance in any real-world situation (note "an example", note "Re RDBs"). But you slipped into the well-worn trench of your teachers, and you perceived the offer as an opportunity for attack on something that cannot defend itself.
The subject needs a separate thread. Before I answer each of your points, the context needs to be laid out. This is important because the myth has been propagated, over a long period, and theoreticians in this space (non-scientists) believe myths, rather than applying the sciences. The myth is held up by veritable pillars of clouds, and those pillars have to be addressed.
Context
1. First and foremost, I neither love nor hate SQL. It is simply one of the languages that I have to use in my work. There is no other language that exists for its purpose (data sub-language for accessing a Relational Database), or that can be contemplated as a potential replacement by undamaged humans, so there is no point crying about how it is good or bad or ugly it is, at doing what it does. It is what it is. So I am SQL-neutral.
2. In order to work effectively, I need to know that language really well. Although most of our code is generated, using an IDE or scripts that generate SQL objects, we have to know the language well, in order to debug errors, and to correct them. Guys in my position have the added burden, that when one of the developers gets stuck with "Hey I can't get this SQL to work", or "SQL can't do division", I have to blow his nose for him, and write it. So I am SQL-capable.
3. I notice that, in every new project, every new team, the starting position of many developers is "SQL can't do this, that is why we have to use temporary tables", etc. Which is false of course, they are simply ignorant, and it is easy to demonstrate the truth. But why does that happen, and why does it happen every time ?
Because they read books. Books that are marketed and propagated throughout the industry. Books full of poison, that cripple their ability to do their jobs, in terms of understanding and using both Relational Databases, and SQL. Therefore any treatment of this subject, the responses to the issues you raise, has to be levelled at the cause, the pig-poop-eating authors of such, and not merely at you, the messenger, the latest carrier of the cancer.
4. I notice that your charges against SQL are identical to the charges that the great harlot of Babylon himself makes, at his slave concentration camp. Hugh Darwen, also known as TweedleDumb. They are not original. You are merely the latest slave, the latest carrier. So you will have to forgive something: while I can normally contain myself (until attacked), and I have not been rude to you, in this thread, I will probably not be able to hide my disdain for the subject; and any such disdain or rudeness is directed at the source, the piggery, and not at you. I suggest that you take this post, something from the real world of sanity, and lay it at the feet of your masters, as an offering.
Analogy
So what do we have here, what does this "SQL is bwoken" myth consists of, what is the basis for each of the attacks (which I will address in detail later) ? What are the cloud-pillars that the pathetic cripples stand on ? The analogy that comes to mind is this.
1. We undamaged humans (excludes Neanderthals) have horses, we have had horses for millennia, we have a long history of using them as beasts of burden, to perfom work for us. Even after the animals were displaced by motor vehicles, we use horses for sport, because we want to, not because we have to. Eg. by the Grace of God, I have had horses for 27 years, and I have ridden a minimum of 40 kms every weekend. The horse is SQL.
2. A brain-damaged cripple comes along, straight out of the loins of the harlot. (Note that cripples can't ride horses.) But he has a long story about how horses are broken and severely limited, because they can't jump ten metre fences, or squeeze through a 20 cm hole in a fence, like a springraffe can.
The pathetic creature does not understand that God created horses for a purpose; that charging a horse for not being a springraffe is mind-numbingly stupid.
-- Aside --
In another post in this thread, you have admitted:
> I concede I was oversimplifying to some extent, and found ERwin guilty of not solving a problem it wasn't designed to solve, ...
Now see if you can be that objective again, see if you have been doing the same thing with SQL. All your charges against SQL herein are accusations re something SQL is not declared to do; not designed to do; cannot be expected to do.
-- End Aside --
-- Aside --
Cripples love to control undamaged humans. It is envy, a sort of revenge against the undamaged, who do have their condition. The special-needs kid on the school bus can't wipe his backside, but he sure can tell the bus driver how to drive.
Consider Stephen Hawkins telling humans about how the universe works.
-- End Aside --
3. Unfortunately, the days of keeping people who are dangerous to society locked up, are over, the seriously deranged as well as dangerous criminals walk the streets and infect society with either their insanity and their criminality, damaging human society further and further. They make movies for us.
So we pander to the insane, the cripples. We ask the silly questions one asks of a 4-year-old who believes in the tooth fairy. We ask, on what basis does he think that a horse should perform like a springraffe, what exactly is a springraffe, why does he think it can jump ten metres. So it turns out, he has never seen a real springraffe, he has only a picture of one, that his maggot-ridden mother painted for him, the springraffe does not exist.
Wait. So we are reduced to comparing a real horse ridden by a real human, that can jump two metres with skill, against a non-existent animal that has fairy-tale capabilities. And we are supposed to believe all that, and answer seriously.
The list of items that the horse "can't do" isn't based on the declared capabilities of the horse; it doesn't spring from the capabilities of a real animal such as a springbok or a giraffe (which would be unfair, but understandable); it springs from the fantasy capabilities of a non-existent mythical beast.
The list of items that SQL "can't do" isn't based on the declared capabilities of the language; it doesn't spring from the capabilities of a real language such as awk or Basic (which would be unfair, but understandable); it springs from the fantasy capabilities of a non-existent mythical beast, a relational algebra as a database language (henceforth RADBL), a /D/.
Only a deranged cripple would mount such an argument. The source is the one percent, the theoreticians who allege that they serve this Relational Database space, who have produced nothing in forty five years, whose only activity is to damage the science that governs this space. The source of that source is the cancer-causing agents: Date, Darwen, Fagin, Pascal, Abiteboul, Hull, Vianu, etc. And all the professors who slavishly spread the cancer.
Argument
The entire argument is a Straw Man. Sure, it is an advanced form, a second generation Straw Man, like the second generation maggots whence it sprung, so those of you generally recognise Straw Man arguments may not recognise this one as such.
First, it is idiotic, self-sabotaging, to attack SQL. It is the only one in that space. There is no competition, and there are no contenders on the horizon. Get a good handle on it and use it for the purpose it was designed. Otherwise you can't perform your job function.
Second, use the right tool for the job. Use a combination of software components or layers. Do not try to get SQL to do things that it wasn't designed to do. If you do, it will be a miserable failure, and the fault it not "SQL can't", the fault is with the person who tried the idiotic thing.
Third, do not compare SQL with anything, except another SQL. No undamaged human compares a horse with a springbok or giraffe, and then faults it for not doing what the springbok or giraffe can do. No one compares awk with Basic and faults either awk or Basic for not doing what the other can do. The notion is insane. Whoever does that is entertaining the source, all the above-named, who are maggot-ridden.
Fourth, the horse; springbok; giraffe; SQL; awk; Basic, all exist. They are real creatures, real languages. We can assess them by various measures, we can compare them with others of their species. But the RADBL is a fiction, completely non-existent. The notion of comparing something real with something fictitious is doubly insane, acceptable only in very small children and those who are locked up.
Fifth, not only is the RADBL a fiction, completely non-existent, its capabilities are fictions upon that fiction. Not only is the RADBL ill-conceived, not-thought-through, many many serious steps naïvely collapsed into a single theoretical step, its capabilities, what it can do, has not been thought-through. It remains the dream of the dream, not the dream of the dreamer.
So it is triply insane for any human to mount such attacks, to use such comparisons, to propose that the horse is somehow lacking because it cannot do the dance of the springraffe, to propose that SQL is somehow broken because it can't perform the fictional dance of the fictional RADBL. That is for humans, they have entertained rotting flesh for so long, the maggots have entered the cranium.
If the source tried it, that would not be insane, it would be criminal, fraudulent, damaging to the industry. Because they are the source, the purveyors of pig-poop, the cause. The crime is worse that that of infected humans.
The second generation Straw Man is the dream that the Straw Man has. Fiction cubed.
Now if you do not understand all that, you will be tricked into catching and holding the Straw Man (advanced model) that they flung at you, and you will burn when they burn it. There are several layers to their fraud. First they have to market and sell the notion of the fictional RADBL. Then they have to market and sell the notion of the fictional capabilities of the fictional language. Then they have to market the notion that those fictions of fictions can be compared with capabilities of real languages. Oh, and that that one day, some way, somehow their fictions of fictions will replace the real language.
That requires serious mental enslavement, a strong and daily doses of the Kool-Aid.
If you do understand all that, you will be immune to such unscientific reasoning, to the cancer of the maggot-ridden sources.
----
SQL Bashing is the sport of champions. Champion cripples that is. Who have maggots in the crania.
Please take this post back to your masters, whence the Straw Man and the charges came.
Cheers
Derek
> On Thursday, 12 February 2015 17:23:44 UTC+11, James K. Lowden wrote:
> > On Tue, 10 Feb 2015 23:06:25 -0800 (PST) Derek Asirvadem <derek.a...@gmail.com> wrote:
> > Thank you for your excellent post. I will get to the rest on the weekend
Now in that otherwise excellent post and ongoing discussion, I had stated:
>>>>
I am aware that the Dates and the Darwens of the world propagate a myth, that SQL is broken, and that you can't do this or that. Let me assure you that the myth is false, self-serving. There is nothing in it. In my three years at the TTM encampment, every so often, either one of the slaves or the slave master himself would post a "here is something SQL cannot do, here is proof that SQL is broken" article. In every instance, I posted a full solution using SQL (nothing but SQL), and proved such to be false.
I am quite willing to do that here. Please give me an example of what SQL cannot do. Re RDBs.
<<<<
Evidently, the mere sight of the words:
> > ... SQL cannot do ...
caused you to entirely forget the context of the thread (Normalisation, the abject failure of theoreticians to Normalise anything) and the post, and to embark on the sport that is dearly beloved of theoreticians: SQL Bashing.
I was treating the difficulties that you were experiencing with SQL as a serious business, and I was offering assistance in any real-world situation (note "an example", note "Re RDBs"). But you slipped into the well-worn trench of your teachers, and you perceived the offer as an opportunity for attack on something that cannot defend itself.
The subject needs a separate thread. Before I answer each of your points, the context needs to be laid out. This is important because the myth has been propagated, over a long period, and theoreticians in this space (non-scientists) believe myths, rather than applying the sciences. The myth is held up by veritable pillars of clouds, and those pillars have to be addressed.
Context
1. First and foremost, I neither love nor hate SQL. It is simply one of the languages that I have to use in my work. There is no other language that exists for its purpose (data sub-language for accessing a Relational Database), or that can be contemplated as a potential replacement by undamaged humans, so there is no point crying about how it is good or bad or ugly it is, at doing what it does. It is what it is. So I am SQL-neutral.
2. In order to work effectively, I need to know that language really well. Although most of our code is generated, using an IDE or scripts that generate SQL objects, we have to know the language well, in order to debug errors, and to correct them. Guys in my position have the added burden, that when one of the developers gets stuck with "Hey I can't get this SQL to work", or "SQL can't do division", I have to blow his nose for him, and write it. So I am SQL-capable.
3. I notice that, in every new project, every new team, the starting position of many developers is "SQL can't do this, that is why we have to use temporary tables", etc. Which is false of course, they are simply ignorant, and it is easy to demonstrate the truth. But why does that happen, and why does it happen every time ?
Because they read books. Books that are marketed and propagated throughout the industry. Books full of poison, that cripple their ability to do their jobs, in terms of understanding and using both Relational Databases, and SQL. Therefore any treatment of this subject, the responses to the issues you raise, has to be levelled at the cause, the pig-poop-eating authors of such, and not merely at you, the messenger, the latest carrier of the cancer.
4. I notice that your charges against SQL are identical to the charges that the great harlot of Babylon himself makes, at his slave concentration camp. Hugh Darwen, also known as TweedleDumb. They are not original. You are merely the latest slave, the latest carrier. So you will have to forgive something: while I can normally contain myself (until attacked), and I have not been rude to you, in this thread, I will probably not be able to hide my disdain for the subject; and any such disdain or rudeness is directed at the source, the piggery, and not at you. I suggest that you take this post, something from the real world of sanity, and lay it at the feet of your masters, as an offering.
Analogy
So what do we have here, what does this "SQL is bwoken" myth consists of, what is the basis for each of the attacks (which I will address in detail later) ? What are the cloud-pillars that the pathetic cripples stand on ? The analogy that comes to mind is this.
1. We undamaged humans (excludes Neanderthals) have horses, we have had horses for millennia, we have a long history of using them as beasts of burden, to perfom work for us. Even after the animals were displaced by motor vehicles, we use horses for sport, because we want to, not because we have to. Eg. by the Grace of God, I have had horses for 27 years, and I have ridden a minimum of 40 kms every weekend. The horse is SQL.
2. A brain-damaged cripple comes along, straight out of the loins of the harlot. (Note that cripples can't ride horses.) But he has a long story about how horses are broken and severely limited, because they can't jump ten metre fences, or squeeze through a 20 cm hole in a fence, like a springraffe can.
The pathetic creature does not understand that God created horses for a purpose; that charging a horse for not being a springraffe is mind-numbingly stupid.
-- Aside --
In another post in this thread, you have admitted:
> I concede I was oversimplifying to some extent, and found ERwin guilty of not solving a problem it wasn't designed to solve, ...
Now see if you can be that objective again, see if you have been doing the same thing with SQL. All your charges against SQL herein are accusations re something SQL is not declared to do; not designed to do; cannot be expected to do.
-- End Aside --
-- Aside --
Cripples love to control undamaged humans. It is envy, a sort of revenge against the undamaged, who do have their condition. The special-needs kid on the school bus can't wipe his backside, but he sure can tell the bus driver how to drive.
Consider Stephen Hawkins telling humans about how the universe works.
-- End Aside --
3. Unfortunately, the days of keeping people who are dangerous to society locked up, are over, the seriously deranged as well as dangerous criminals walk the streets and infect society with either their insanity and their criminality, damaging human society further and further. They make movies for us.
So we pander to the insane, the cripples. We ask the silly questions one asks of a 4-year-old who believes in the tooth fairy. We ask, on what basis does he think that a horse should perform like a springraffe, what exactly is a springraffe, why does he think it can jump ten metres. So it turns out, he has never seen a real springraffe, he has only a picture of one, that his maggot-ridden mother painted for him, the springraffe does not exist.
Wait. So we are reduced to comparing a real horse ridden by a real human, that can jump two metres with skill, against a non-existent animal that has fairy-tale capabilities. And we are supposed to believe all that, and answer seriously.
The list of items that the horse "can't do" isn't based on the declared capabilities of the horse; it doesn't spring from the capabilities of a real animal such as a springbok or a giraffe (which would be unfair, but understandable); it springs from the fantasy capabilities of a non-existent mythical beast.
The list of items that SQL "can't do" isn't based on the declared capabilities of the language; it doesn't spring from the capabilities of a real language such as awk or Basic (which would be unfair, but understandable); it springs from the fantasy capabilities of a non-existent mythical beast, a relational algebra as a database language (henceforth RADBL), a /D/.
Only a deranged cripple would mount such an argument. The source is the one percent, the theoreticians who allege that they serve this Relational Database space, who have produced nothing in forty five years, whose only activity is to damage the science that governs this space. The source of that source is the cancer-causing agents: Date, Darwen, Fagin, Pascal, Abiteboul, Hull, Vianu, etc. And all the professors who slavishly spread the cancer.
Argument
The entire argument is a Straw Man. Sure, it is an advanced form, a second generation Straw Man, like the second generation maggots whence it sprung, so those of you generally recognise Straw Man arguments may not recognise this one as such.
First, it is idiotic, self-sabotaging, to attack SQL. It is the only one in that space. There is no competition, and there are no contenders on the horizon. Get a good handle on it and use it for the purpose it was designed. Otherwise you can't perform your job function.
Second, use the right tool for the job. Use a combination of software components or layers. Do not try to get SQL to do things that it wasn't designed to do. If you do, it will be a miserable failure, and the fault it not "SQL can't", the fault is with the person who tried the idiotic thing.
Third, do not compare SQL with anything, except another SQL. No undamaged human compares a horse with a springbok or giraffe, and then faults it for not doing what the springbok or giraffe can do. No one compares awk with Basic and faults either awk or Basic for not doing what the other can do. The notion is insane. Whoever does that is entertaining the source, all the above-named, who are maggot-ridden.
Fourth, the horse; springbok; giraffe; SQL; awk; Basic, all exist. They are real creatures, real languages. We can assess them by various measures, we can compare them with others of their species. But the RADBL is a fiction, completely non-existent. The notion of comparing something real with something fictitious is doubly insane, acceptable only in very small children and those who are locked up.
Fifth, not only is the RADBL a fiction, completely non-existent, its capabilities are fictions upon that fiction. Not only is the RADBL ill-conceived, not-thought-through, many many serious steps naïvely collapsed into a single theoretical step, its capabilities, what it can do, has not been thought-through. It remains the dream of the dream, not the dream of the dreamer.
So it is triply insane for any human to mount such attacks, to use such comparisons, to propose that the horse is somehow lacking because it cannot do the dance of the springraffe, to propose that SQL is somehow broken because it can't perform the fictional dance of the fictional RADBL. That is for humans, they have entertained rotting flesh for so long, the maggots have entered the cranium.
If the source tried it, that would not be insane, it would be criminal, fraudulent, damaging to the industry. Because they are the source, the purveyors of pig-poop, the cause. The crime is worse that that of infected humans.
The second generation Straw Man is the dream that the Straw Man has. Fiction cubed.
Now if you do not understand all that, you will be tricked into catching and holding the Straw Man (advanced model) that they flung at you, and you will burn when they burn it. There are several layers to their fraud. First they have to market and sell the notion of the fictional RADBL. Then they have to market and sell the notion of the fictional capabilities of the fictional language. Then they have to market the notion that those fictions of fictions can be compared with capabilities of real languages. Oh, and that that one day, some way, somehow their fictions of fictions will replace the real language.
That requires serious mental enslavement, a strong and daily doses of the Kool-Aid.
If you do understand all that, you will be immune to such unscientific reasoning, to the cancer of the maggot-ridden sources.
----
SQL Bashing is the sport of champions. Champion cripples that is. Who have maggots in the crania.
Please take this post back to your masters, whence the Straw Man and the charges came.
Cheers
Derek
Derek Asirvadem
Feb 18, 2015, 4:56:00 AM2/18/15
to
James
> On Thursday, 12 February 2015 17:23:44 UTC+11, James K. Lowden wrote:
Ok, now that we have defined the problem, the context, the creatures who propose it for what they are, that you are just the messenger, the sock puppet, we can deal with the specific charges.
> On Thursday, 12 February 2015 17:23:44 UTC+11, James K. Lowden wrote:
Please keep in mind, I am SQL-neutral, SQL-capable, and my tolerance for maggots is pretty low.
> > Please give me an example of what SQL cannot do.
Ok, as long as that context is keep in mind, not forgotten, I will entertain you.
> Tuple comparison,
> select ... where R.(a, b) = S(a, b)
> select ... where (a,b) in (select a, b from S)
Huh ?
Row comparison is dead easy in SQL. Multiple column comparisons are not a problem.
You might be confusing yourself by mixing SQL syntax with the non-existent RADBL syntax, as you have above. If you give me a real world example, I will code it for you, probably while I am sleeping. Please nominate one, or direct me to the Security columns, or use this model (probably good for all your queries), and nominate the rows that you cannot compare.
http://www.softwaregems.com.au/Documents/Student%20Resolutions/Parent%20Child.pdf
Or, if you have figured the SQL out, retract the charge
> Column comparison,
> check R.a = S.a where R.b = 'Y'
Ditto, ditto, ditto.
We do have a CHECK command, but it can't be used in that manner. Do you mean SELECT ?
Not sure, but if I translate the cryptic fictions into meaningful intentions, and then translate that into language code, are you trying to do something like this (using my supplied data model, plus obvious inventions):
SELECT LastName,
________FirstName
____FROM (
____( SELECT LastName,
____________ FirstName
________FROM Person
________WHERE Gender = "M"
________) AS MALE
____( SELECT LastName,
____________ FirstName
________FROM Person
________WHERE Gender = "F"
____________AND Status = "Pregnant"
________) AS FEMALE
____WHERE MALE.LastName != FEMALE.LastName
As is true for all real languages (ie. excluding fictitious ones, of course), SQL is much easier to read, to debug, if it is (a) formatted consistently, and (b) limited to one operand per line. But you are free retain your cryptic style, to excise the white space, and treat the entire command as a single string. That is what the code generators and report tools do, not for reading by humans.
SELECT LastName,FirstName FROM(SELECT LastName,FirstName FROM Person WHERE Gender="M") AS MALE (SELECT LastName,FirstName FROM Person WHERE Gender="F" AND Status="Pregnant") AS FEMALE WHERE MALE.LastName!=FEMALE.LastName
Sorry if something got lost in the two levels of translation. Please feel free to correct me, and I will re-code it for you.
> Universal quantification is similar. Needed for relational division.
Been done to death. You are operating at a level that is possibly a notch or two above the imbecile Celko, but well below the boys from the backwoods of Wisconsin.
Celko (for reference only, do not read):
https://www.simple-talk.com/sql/t-sql-programming/divided-we-stand-the-sql-of-relational-division/
McCann (read):
http://www.cs.arizona.edu/people/mccann/research/divpresentation.pdf
Go hunting in Wisconsin.
Universal quantification is a non-issue.
Relational division is a non-issue.
Note in particular, McCann's caution, slide 18, item 2. You are using the most difficult of four methods.
Of course, you must use the right tool for the job. Of the four methods, for any given scenario, one is usually easier and clearer than the others, meaning that there is not one best method for all scenarios.
Additionally, when you get experience with each method, your code will improve. Eg, I can code the quantification method without the butt-ugly GROUP BYs.
> Yes, you can accomplish those in SQL by writing it out more verbosely
There is no non-verbose switch in SQL. Deal with it. It is dishonest to posit "more verbosely" when there is no "non-verbose" option.
> or, as with universal quantification (find students who have taken
> all required classes), you can employ De Morgan and use "not not
> exists".
Only if you do not understand Derived Tables (Inline Views in Oracle). Ie. a full SELECT command feeding a FROM item. Theoreticians don't even know that it exists.
> If you have that filed under "can do", not only do we disagree
> on the meaning of "can",
No. "Can" is defined in the SQL manual of your platform choice. You have weird and unreasonable expectations of "can", ala relational algebra as commands. Oh, oh, if the horse can jump one metre, why can't it jump ten metres. We read the RA on one side, the manual on the other side, and we fill in the requirement between the two sides, without ado, fanfare, hair-pulling, dummy-spitting.
You are stuck on one side, dummy-spitting.
Can land is much more peaceful that JW land.
> but you will find yourself defending the use
> of lower-level constructs to implement concepts defined by relational
> algebra.
Your statement is self-contradictory. You absolutely do understand that SQL is a low-level language, there is nothing in it but "low-level constructs", and you cry about it not being a high-level language. And especially silly when that high-level language is fictitious.
The non-acceptance of RADBL, that SQL is not declared to accept is a non-issue, Straw Man, already treated.
Besides SQL being indefensible, which I agree, I am not even called to defend anything here. Thus far, all I am doing is showing someone how to do something in a tool that they are less familiar with than I.
> That smell you smell is awk.
Yes. A bit silly to try inside an SQL platform.
> Table comparison,
> where T = (select ... from S where ...)
Stupid to execute inside a server during production, but lets do so anyway.
Dead simple. Use the couplet I gave and restate the gibberish as a real world example please.
> SQL can't constrain views in any way, can't use views as a FK target.
???
The View is in fact a SELECT statement.
1. While it is very silly to implement views of views, and views of views of views, it is not illegal. You must be using a non-SQL.
___ Very Silly. Theoreticians often do not differentiate between base relations (tables) and derived relations (views). That is a huge impediment, and it poses a problem everywhere, here as well.
___ When you implement in implementation land, you cannot remain in the freedom of abstraction in theory land. That will trip you up.
___The fact that you are writing SQL means you are stepping out of fiction land, and into implementation land. Deal with it, or do not take the job.
___ Get your head around the notion of a single-level view, ie. that uses tables only, not views, and your problem will disappear.
2. If "Constraining" means stating a set of conditions, then "constraining" a View is legal. You must be using a non-SQL.
3. In any case, even if you are using a non-SQL, to overcome that obstacle, simply write a single-level view, with the "constraint" in the WHERE clause.
> I would like to be able to use a union as a domain; SQL cannot.
It sounds simple enough, but there is not enough detail to code from. Can you provide a real world example. Use the couplet is it is suitable.
> When people say it's
> "not relational", that's not what they mean. They mean it does not
> express relational concepts directly or particularly well, and
> sometimes -- bags, column order -- ignores it entirely.
Yeah, I know all that.
awk doesn't launch windows or translate Swahili. So what. If you use it, you know that, and you are using it for the things that awk DOES, not for what it does NOT do.
SQL doesn't accept RADBL as input. So what. No one ever said it could.
> When people say it's
> "not relational", that's not what they mean. They mean it does not
> express relational concepts directly or particularly well, and
> sometimes -- bags, column order -- ignores it entirely.
SQL doesn't accept RADBL as input. So what. No one ever said it could.
You married the girl for her dowry. It is stupid, self-damaging, to then spend your life complaining about the fact that she snores in bed; leaves the toilet seat down; passes wind without opening the window; doesn't speak Swahili; doesn't shave her armpits often enough; and has an obsession with shoes. If you do, it will damage your own life, as well as your married life. Keep the dowry in the forefront of your mind.
No one has ever declared that SQL is anything but a low-level data sub-language. So it is really really silly to cry about the fact that it is:
- NOT a full language
___ it is what it is, and it isn't what it isn't, choose the correct set of layers
___ do not attempt to do everything in SQL
- NOT a high-level language
___ it is not a can opener either
- NOT capable of accepting RADBL
___ it doesn't accept Swahili or Urdu either
- NOT capable of performing all relational functions elegantly
___ it does perform all functions, some of them are inelegant
- flatulent, verbose
___ all low-level languages are, especially if you have meaningful (long) column names
Get an IDE, it costs only fifty bucks. They have been availble since 1993. You are working on a low-level data sublanguage with tools that are twenty two years behind the times. Or, if you can't afford fifty bucks, stop complaining about SQL being the problem, start complaining about your income stream.
Relational algebra is not a god. It is not the definitive set of operations that a data sub-language CAN let alone SHOULD implement. There are many things that are not acceptable in an implementation, that are quite acceptable in the algebra. But for the sound understanding of that in the commercial vendors, we would have more chaos than we have now.
Another category is this. The algebra quite rightly is limited to relational operations, and in a database implementation, there is a whole set of operations that must be implemented for databases, that are absent the algebra.
If you do not understand the above two issues, you will have problems with any implementation.
The remainder of your complaints are this. They are not in fact complaints, they are marketing, the marketing of a longing that only you, that tiny fraction of the market, that 1%, have. We couldn't care less about a language that accepts relational algebra as commands to change the database. You care a lot. Ok, fine. End of story, for happily married men.
But that is not enough for you. You have to market the idea of what we are missing. No one in the 99% cares. They only care that the database operations have a sound theory behind it, they don't care about how that theory is expressed, let alone that that expression should be taken literally, as a command. But that doesn't stop you, you have to go, house to house, like a jehovah's witness, and market the very very very strange "heaven" that we are missing out on.
Get a grip.
And don't be "hurt" that we slam the door in your face and go back to our newspaper.
> SQL is a relic of another age, the last man standing after RJE, COBOL,
> Cullinet, PL/1 and all the rest have disappeared. To the economics of
> those days we owe the fact that we use SQL and not Ingres's QUEL, a
> much better language.
Piece of garbage that never worked, beloved by academics (they have a fetish for things that do not work); keeps re-inventing itself as the latest greatest thing that doesn't work. At least it is better than a /D/og, because (a) Stonebraker wrote some code, and lead the way, while Darwen write write a single line, but seduces young minds into writing the impossible dream, complete with windmills, and (b) proved it as a possibility.
Back to SQL.
You seem to have totally missed the reality on the physical plane. SQL is not "of another age", it is of this age. It is current, and growing both within the language and the vendor offerings and features, and with the great number of flavours being written. You are in flat denial of reality.
Of course, it is a low-level language, fortunately and unfortunately, depending on you particular task at hand. For the developers, I give them a full-blown IDE, such as RapidSQL or SQLProgrammer. Get one. I myself use DBArtisan, which is really a DBA IDE, big bucks.
Consider this. Take any one of my projects. I implement the entire RDB plus one entire app (full OO, etc). The whole ship is running. Now what about the hundreds of users who need to access the RDB for various scheduled and ad hoc reports ? Do they sit there and cry like a baby because SQL is low-level; verbose; flatulent; doesn't take statistical formulæ as input; etc ? Do they ? No.
Why ? I sit down with each group, discuss their needs, and give them and and all of the following. Remember it is an Open Architecture World out here:
- ODBC connection to MS Access/Excel
- Simple report tool, ala Crystal Reports
- SAS for statisticians and number crunchers
Everyone is blissfully happy. No one writes SQL, they just know it exists somewhere, call one of the developers if the see a funny message.
So the point is this, even the dumbest of dumb users is operating at a level that is significantly above yours. You are working in a SQL developer role, you refuse to get a developer tool, and you complain about the langauge, instead of complaining about the lack of a tool. G.E.T__A.N__S.Q.L__I.D.E.
> The strange, ignorant time we currently live in
> promises very little progress, if any, because users of databases
> doen't realize how much is being lost, never mind forgone.
Progress that is relevant only to that 1% who can't get an IDE.
How much is lost. Hilarious. You are marketing again, about a false heaven, the fictitious dreams of the fictional language. We couldn't care less.
> If your assertion is that SQL can, after a fashion, express any
> relational algebra function, I concede the point.
I did, and with the above qualifiers and direction, which makes the "after a fashion" a very silly statement.
----
We could end the SQL section here. But there are strange things, that I did not expect an old hand such as *you*, would present under this heading, so let me tackle them.
Now for the really tiny ... unbelievable, coming from you.
> Why does UNION (and similar) require column order to match, but not
> name?
You do understand that each set that feeds an UNION is a result set, a derived relation, don't you ? That it is your job as a programmer to feed the UNION with consistent sets ? There is no suggestion that the platform performs magical mystical transformations ?
The notion of the Heading being tightly coupled to the column is a TTM absurdity. Complete pig poop. It doesn't happen in SQL, so in any case, it is silly to expect the non-feature here. Same as complaining about the 1930's guitar in your hands not having the range of an electric guitar of 1990's, it does not apply. Either use the guitar in your hands or get off the stage. Complaining is for maggot-ridden old women such as Darwen.
The column DOMAINS must match, otherwise the UNION breaks.
The only way to get the domains to match is to get the column order in each of the sets to match.
The column names are therefore irrelevant. Most platforms take the headings in the first set as nominal. They could just as easily take them from the last set. Since only you know the meaning of the union-ed columns, you are free to GIVE the headings. But you don't, you complain that the low level language doesn't perform high-level functions that no one declared it could.
> Why does SELECT return duplicate column names
Because *you* told it to return duplicate columns,
--AND-- *you* failed to distinguish the difference to between them,
--AND-- *you* failed to inform the SELECT about such.
I never have duplicate column names returned to me.
awk does the same, why don't you complain about that ?
> or permit unnamed
> columns?
Why not ?
It is a disgusting lie, typical of Darwen, that it is a "column".
The reason the "column" has no name is because it is computed, it is not a column, and your platform could not figure out which source column applied the most (ie. my platform will do a better job than yours, but still, naming a computed column is not the parsers job; it is your job).
Just give the result set column a name. AS or [].
awk does the same, why don't you complain about that ?
> Why SELECT DISTINCT but UNION ALL?
???
I have UNION ALL, UNION nothing, and UNION DISTINCT. They each return different results. Yours must be non-SQL.
> Why must FROM appear only
> between SELECT and WHERE?
It was arbitrary. Now it is history. Deal with it.
awk requires print operands to appear between "print" and the line terminator. Why don't you complain about awk being so stupid ?
> (Why even say "SELECT"?)
No idea what you mean. To differentiate it from the other three verbs ? A default verb would be a stupid concept in a data sub-language.
> What purpose does
> HAVING serve anymore?
Well, it is less of an use now than it was in the 80's, but that doesn't make it use-less, refer McCann Division method 4, slide 27.
It cannot be deprecated. We have code out there that we need not change, simply because better operators have arrived since then.
> Why do subqueries require aliases even when
> unreferenced?
SQL doesn't. Mine doesn't. Yours must be non-SQL.
> Just look at the butt-ugly porcine ungainliness of UPDATE. Updating
> one table from another has to be the most cumbersome, verbose, and
> redundant aspect of SQL, not that it lacks competition (except in any
> other language). Why can we not say instead
>
> R(a, b, c) = S(a, b, c) WHERE R.x = S.x
Because SQL does not parse Swahili, or Urdu, or RADBL, no one stated that it could, silly to expect bread from the butcher.
If you translated that giberish into recognisable operations, it is very easy to code in SQL.
UPDATE is cumbersome only if you do not understand that:
- the target is a single table
- the FROM should be a full SELECT.
> SQL is indefensible.
Of course. Only a fool would attack a low-level language. Only another fool would defend it.
But, SQL is not the problem. As detailed in this and the first post.
Your serve. ;-)
I trust you will appreciate my new use of colour, for this new thread.
----
Now, if you do give me any further SQL "problems" to deal with, please limit them to:
- real world example
- Relational Databases
While I can read gibberish, I hope I have detailed the silliness of expecting either the SQL parser, or me, to translate gibberish (or Swahili) to SQL, enough, that you will refrain from doing so in future.
Thank you for your other posts, which are excellent.
Cheers
Derek
Dieter Nöth
Feb 18, 2015, 5:28:41 AM2/18/15
to
Derek Asirvadem wrote:
> I have UNION ALL, UNION nothing, and UNION DISTINCT.
> They each return different results. Yours must be non-SQL.
Could you elaborate on those different results, I always thought that
> I have UNION ALL, UNION nothing, and UNION DISTINCT.
> They each return different results. Yours must be non-SQL.
UNION is the same as UNION DISTINCT (DISTINCT being simply the default).
Dieter
Derek Asirvadem
Feb 18, 2015, 7:42:23 AM2/18/15
to
Cheers
Derek
Derek Asirvadem
Feb 18, 2015, 8:15:07 AM2/18/15
to
> On Wednesday, 18 February 2015 20:56:00 UTC+11, Derek Asirvadem wrote:
Dieter's correction has prompted me to examine this again.
> > Why SELECT DISTINCT but UNION ALL?
The database you are operating on is supposed to be Relational. Relational prohibits duplicate rows (note, rows, not records). SQL cannot force you to implement unique rows, same as awk cannot force you to implement Relational Keys that are not duplicated (awk is easier, though). Therefore the assumption is that the rows in your tables are unique. Therefore SELECT always shows exactly the rows you selected, including dupes, otherwise you would not see them, and DISTINCT is an option to tell it to suppress dupes.
The one and only method of eliminating dupes in the base relations (tables), to achieving that Relational demand, is to implement an unique index. It is not SQLs job to do that for you, just as it is not awks. Something that the Dates and Darwens and Abitebouls of the world simply do not understand, they need a wet nurse.
SELECT rows is not an aggregation.
For exactly the same reasoning (p1) ... but the context for UNION is different ... since UNION is an aggregation of sets, and you are supposed to have the SELECTs that feed it in good working order, etc, you don't want dupes. If you do have dupes, it is not a gross error, such as dupes in base relations (tables), but either (a) dupes in the SELECTS, ie. derived relations, xor (b) dupes across the SELECTs, which are much harder to control and eliminate. Aggregation and other operations would return the incorrect results if dupes were included. So the default is to exclude those dupes, and ALL is an option to show them.
Cheers
Derek
Dieter's correction has prompted me to examine this again.
> > Why SELECT DISTINCT but UNION ALL?
The one and only method of eliminating dupes in the base relations (tables), to achieving that Relational demand, is to implement an unique index. It is not SQLs job to do that for you, just as it is not awks. Something that the Dates and Darwens and Abitebouls of the world simply do not understand, they need a wet nurse.
SELECT rows is not an aggregation.
For exactly the same reasoning (p1) ... but the context for UNION is different ... since UNION is an aggregation of sets, and you are supposed to have the SELECTs that feed it in good working order, etc, you don't want dupes. If you do have dupes, it is not a gross error, such as dupes in base relations (tables), but either (a) dupes in the SELECTS, ie. derived relations, xor (b) dupes across the SELECTs, which are much harder to control and eliminate. Aggregation and other operations would return the incorrect results if dupes were included. So the default is to exclude those dupes, and ALL is an option to show them.
Cheers
Derek
Erwin
Feb 18, 2015, 8:49:36 AM2/18/15
to
Op woensdag 18 februari 2015 13:42:23 UTC+1 schreef Derek Asirvadem:
>
> I was typing faster than I was thinking.
>
> Cheers
> Derek
Alas nowhere near an infrequent event with you.
> I was typing faster than I was thinking.
>
> Cheers
> Derek
Erwin
Feb 18, 2015, 9:01:15 AM2/18/15
to
Op woensdag 18 februari 2015 11:28:41 UTC+1 schreef Dieter Nöth:
Dieter,
"elaborations" by Mr. Pig Poop are not worth reading. They are biased by very questionable prejudices at best, hopelessly uninformed and outright wrong at worst.
One example : Mr. Pig Poop wrote "The notion of the Heading being tightly coupled to the column is a TTM absurdity. Complete pig poop. It doesn't happen in SQL, so in any case, it is silly to expect the non-feature here." I invite you to read up on SQL's UNION CORRESPONDING to see the evidence of the contrary.
"elaborations" by Mr. Pig Poop are not worth reading. They are biased by very questionable prejudices at best, hopelessly uninformed and outright wrong at worst.
One example : Mr. Pig Poop wrote "The notion of the Heading being tightly coupled to the column is a TTM absurdity. Complete pig poop. It doesn't happen in SQL, so in any case, it is silly to expect the non-feature here." I invite you to read up on SQL's UNION CORRESPONDING to see the evidence of the contrary.
Derek Asirvadem
Feb 18, 2015, 9:50:37 AM2/18/15
to
I must have done something right, the sewers are seething, the maggots are squirming.
> On Thursday, 19 February 2015 01:01:15 UTC+11, Erwin wrote:
> "elaborations" by Mr. Pig Poop are not worth reading. They are biased by very questionable prejudices at best, hopelessly uninformed and outright wrong at worst.
The usual sniping, from under manhole covers, labels, generalisations, without evidence, without a single specific point. Never a direct attack, always an infection, an infestation, a contamination. Typical maggot, attached to the anus.
I suppose I should take it as a compliment, that you copy my expressions, and forget the fact that subhumans have no originality. Thank you.
> One example : Mr. Pig Poop wrote "The notion of the Heading being tightly coupled to the column is a TTM absurdity. Complete pig poop. It doesn't happen in SQL, so in any case, it is silly to expect the non-feature here." I invite you to read up on SQL's UNION CORRESPONDING to see the evidence of the contrary.
1. Your mother sow decries SQL. She cannot at the same comply with it, and expect to be taken seriously. Oh yeah, she contradicts herself all the time. She shouldn't ever be taken seriously.
2. The evidence will bury you. Most of us SELECT without UNION. So let's get this right: the fraud uses a marginal case, the only one where naming is used, to justify a "law". And even then, one has to supply the names, and thus one can supply any set of names.
Typical maggot permanently attached to the anus.
Thank you for proving that, both points. I love it.
Imbecile.
You need to take the phylactery off your forehead and shove it in your, um, er, mouth. Since you do everything backwards, as children of the devil do.
Eurhm is the sound a maggot makes when it is chock-full of pig poop, just before it explodes.
God bless
Derek
> On Thursday, 19 February 2015 01:01:15 UTC+11, Erwin wrote:
> "elaborations" by Mr. Pig Poop are not worth reading. They are biased by very questionable prejudices at best, hopelessly uninformed and outright wrong at worst.
I suppose I should take it as a compliment, that you copy my expressions, and forget the fact that subhumans have no originality. Thank you.
> One example : Mr. Pig Poop wrote "The notion of the Heading being tightly coupled to the column is a TTM absurdity. Complete pig poop. It doesn't happen in SQL, so in any case, it is silly to expect the non-feature here." I invite you to read up on SQL's UNION CORRESPONDING to see the evidence of the contrary.
2. The evidence will bury you. Most of us SELECT without UNION. So let's get this right: the fraud uses a marginal case, the only one where naming is used, to justify a "law". And even then, one has to supply the names, and thus one can supply any set of names.
Typical maggot permanently attached to the anus.
Thank you for proving that, both points. I love it.
Imbecile.
You need to take the phylactery off your forehead and shove it in your, um, er, mouth. Since you do everything backwards, as children of the devil do.
Eurhm is the sound a maggot makes when it is chock-full of pig poop, just before it explodes.
God bless
Derek
Derek Asirvadem
Feb 18, 2015, 10:13:58 AM2/18/15
to
More detail.
> On Wednesday, 18 February 2015 20:56:00 UTC+11, Derek Asirvadem wrote:
>
> > SQL can't constrain views in any way, can't use views as a FK target.
>
> ???
>
> The View is in fact a SELECT statement.
>
> 1. While it is very silly to implement views of views, and views of views of views, it is not illegal. You must be using a non-SQL.
>
> [a] Very Silly. Theoreticians often do not differentiate between base relations (tables) and derived relations (views). That is a huge impediment, and it poses a problem everywhere, here as well.
>
> ???
>
> The View is in fact a SELECT statement.
>
> 1. While it is very silly to implement views of views, and views of views of views, it is not illegal. You must be using a non-SQL.
>
> [b] When you implement in implementation land, you cannot remain in the freedom of abstraction in theory land. That will trip you up.
> [c] The fact that you are writing SQL means you are stepping out of fiction land, and into implementation land. Deal with it, or do not take the job.
> [d] Get your head around the notion of a single-level view, ie. that uses tables only, not views, and your problem will disappear.
>
> 2. If "Constraining" means stating a set of conditions, then "constraining" a View is legal. You must be using a non-SQL.
>
> 3. In any case, even if you are using a non-SQL, to overcome that obstacle, simply write a single-level view, with the "constraint" in the WHERE clause.
4. The reason you can't use a View as an FK "target" is a good one. Same as:
> 2. If "Constraining" means stating a set of conditions, then "constraining" a View is legal. You must be using a non-SQL.
>
> 3. In any case, even if you are using a non-SQL, to overcome that obstacle, simply write a single-level view, with the "constraint" in the WHERE clause.
>>>
We let brilliant but impotent theoreticians create their absurd SELECTS, and thresh the data 50 ways to Sunday. But we don't let them inflict that insanity on the rest of the users. Ie. We do not let them *create a View* from absurd SELECTs, such as:
- duplicate column names
- establish a Primary or Unique Key on a View
- other, similar forms of insanity
All of which are beloved by theoreticians who can't tell the difference between base relationa (tables in implementation land) and derived relations (the result of a SELECT, including View). Refer [a] above.
MS with their very very marvellous humaniversity and 500 professors, have gone the whole hog (ie. piggery): they give you, ta da, The Materialised View. The ultimate in a single self-contradicting term.
<<<<
Let's see now, Normalisation; PKs; FKs, apply only to base relations (tables). Not to derived relations (SELECTs, Views).
Let's see now, views are unstable, they disappear and reappear as often as theoreticians change their views (sorry), I mean their relations (sorry), I mean their shorts. And tables are a bit more stable, especially if we do not GRANT anything but SELECT to the theoreticians.
So for the reasons given above, since the notion of an FK on a base relation (table) referencing an ever-changing View, is totally unsound (except to the person who changes it everyday), we disallow it.
> > Just look at the butt-ugly porcine ungainliness of UPDATE. Updating
> > one table from another has to be the most cumbersome, verbose, and
> > redundant aspect of SQL, not that it lacks competition (except in any
> > other language). Why can we not say instead
> >
> > R(a, b, c) = S(a, b, c) WHERE R.x = S.x
>
> Because SQL does not parse Swahili, or Urdu, or RADBL, no one stated that it could, silly to expect bread from the butcher.
>
> If you translated that giberish into recognisable operations, it is very easy to code in SQL.
>
> UPDATE is cumbersome only if you do not understand that:
> - the target is a single table
> - the FROM should be a full SELECT.
>
- SQL is Structured *QUERY* Language
- When Chamberlain and Boyce wrote System R, there was no INSERT, UPDATE or DELETE
- All writes were via CICS/TCP, through the back door
- which was of course incomplete, so when they had to package it for market, as SQL, that had to be added, to a genuine Query language that had no write verbs
Therefore consider:
- the porcine ungainliness is only if one does not appreciate that DELETE and UPDATE are the target of a SELECT, a pipe so to speak
And to avoid "difficulty":
- forget the UPDATE, write the SELECT, and only the SELECT for the target rows
- then pipe it into the FROM of the UPDATE
----
Ok, there is a fair amount of reason coming out in these answers, that has a value. I have to concede, they are not stupid questions, they are simply the questions of a novice. Unfortunately tainted with a huge bias for fictitious capabilities of fictional languages, learned bias.
Cheers
Derek
0 new messages