[Discuss] SQL discussion

[Jerry Feldman]

On 01/13/2015 02:49 PM, Richard Pieri wrote:
> On 1/13/2015 1:39 PM, markw at mohawksoft.com wrote:
>> Semantic arguments over canonically understood terms is not a good
>> start.
>> When one says "a SQL database," everyone knows what is being discussed.
>
> The only time that I've ever seen "a SQL database" having a
> "canonically understood" meaning is in regards to specific instances
> of Microsoft SQL Server databases. Then again, the fact that we're
> even having this argument suggests that when one says "a SQL
> database," /not/ everyone knows what is being discussed.
>
>
>>> SQL is a database interface language. It was designed specifically for
>>> use with relational tables.
>>
>> That is part of it, true, but not all of it.
>
> No, that's the entirety of it: SQL was developed specifically for use
> with relational data. Period. You can argue that it's not but if
> you're going to do that then I suggest taking it up with the guys at
> IBM who designed it.
Absolutely yes. SQL was the language used by IBM's Sequel product. I sat
on the ANSI database standards committee at the time when we released
the SQL standard. We also released the standard for network databases. I
think we are talking back in the early 1980s. But before that in the
1970s my company at the time was choosing a database for our IBM
mainframes, and we had a few choices, IBM's system that was a
hierarchial database, and a few others. But, on the committee we did
struggle with a number of items. For instance, should the committee
define number types. But we decided that number types were really the
responsibility of the computer languages. We added a number of things,
but later decided that IBM's Sequel was the defacto standard and we
reset to that.
>
>
>>> On the other foot, SQL is absolutely terrible for queries against
>>> unstructured and multi-dimensional data.
>>
>> LOL, *everything* else is just as bad.
>
> The proliferation of post-relational databases in high-profile
> applications suggests that this is merely your opinion. By
> "high-profile" I mean the likes of Ameritrade and Kaiser Permanente. I
> list these two because I had a very, very, very indirect hand in their
> deployments.
>
>
>>> It's difficult to implement
>>> queries against these kinds of data with SQL.
>>
>> Why?
>
> Because SQL is built on two dimensional algebra. Two dimensional math
> cannot easily encompass three or more dimensions.
>
>
>>> Such queries are much more
>>> complex in SQL than their native equivalents and they are much
>>> slower as
>>> a direct consequence of this complexity.
>>
>> Why?
>
> With SQL you perform multiple queries and figure out how to combine
> the results. With a native multi-dimensional query you perform one
> query and receive one result.
>
>
>> Rhetorical nonsense. Assertions without explanations.
>
> No, it's just you being hide-bound in re. SQL and relational databases.
>
> Hm. I seem to recall something... wasn't it one of your posts that I
> replied with a quip to the effect that when all you have is a RDBMS
> then every problem looks like a table?
>

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:B7F14F2F
PGP Key fingerprint: D937 A424 4836 E052 2E1B  8DC6 24D7 000F B7F1 4F2F