On 01/13/2015 02:49 PM, Richard Pieri wrote: > On 1/13/2015 1:39 PM, ma...@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 <g...@blu.org> Boston Linux and Unix PGP key id:B7F14F2F PGP Key fingerprint: D937 A424 4836 E052 2E1B 8DC6 24D7 000F B7F1 4F2F _______________________________________________ Discuss mailing list Discuss@blu.org http://lists.blu.org/mailman/listinfo/discuss