Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] SQL discussion



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





BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org