ajayshah@aludra.usc.edu (Ajay Shah) (07/06/90)
At the outset, let me say i'm a total novice to databases; i've
just done a little work with databases and was curious. So here
goes:
I've tried writing SQL queries and found it to be
tremendously irritating, mainly because it's nonprocedural.
Now i'm sure 99% of the programmers of the world prefer
thinking procedural programming languages over
nonprocedural ones. I'm also a sufficiently fluent HLL
programmer to be certain it's more painful generating SQL
that it would be generating a procedural query language.
I'm also nearly certain optimising the speed of query would
be easier with a procedural query language.
So why is SQL defined the way it is?
Is it supposed to be some kind of standard which imposes
restrictions on the internal organisation of a RDBMS, so
that no "real-life" queries would use SQL? Or is it just a
rotten way of writing queries which somehow happened to
become a standard?
Are there any prominent standards for procedural queries on
relational databases? Is SQL a portable standard: i.e.,
can one expect to be able to blindly take a SQL script
written with one RDB (say, Unify) and make it work with
another (say, Oracle). If so, then does that not reduce
the major RDB alternatives (Unify, Ingress, Oracle, etc) to
pretty generic alternatives (they all become SQL engines)?
In that case, what is it that differentiates two vendors?
I'd use Unix facilities for file-handling and backups etc,
anyway, so *if* SQL is totally portable and a 100% standard
then I wouldn't care about which RDB I used.
I believe IBM has a major database called DB2. What is it
like? I'm mostly used to old versions of Unify (3.1 and
3.2) and have pretty much been out of touch with databases
since.
_______________________________________________________________________________
Ajay Shah, (213)747-9991, ajayshah@usc.edu
The more things change, the more they stay insane.
_______________________________________________________________________________Bron@cup.portal.com (George Bron Faison) (07/08/90)
One cannot add water to cup that is already full, grasshopper... Bron ...................................................................... portal!cup.portal.com!Bron Bron@cup.portal.com Modern Office Systems Technology, Inc. George "Bron" Faison 6006-B Mechanicsville TurnPike (804) 730-1467 Mechanicsville VA 23111 ......................................................................
gsn@sclcig.uucp (Georg Nikodym) (07/08/90)
In article <10632@chaph.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: > >At the outset, let me say i'm a total novice to databases; i've >just done a little work with databases and was curious. So here >goes: > > I've tried writing SQL queries and found it to be > tremendously irritating, mainly because it's nonprocedural. (stuff deleted) > So why is SQL defined the way it is? > > Is it supposed to be some kind of standard which imposes > restrictions on the internal organisation of a RDBMS, so > that no "real-life" queries would use SQL? Or is it just a That's the IBM way, make something really ugly, terrible and cumbersome and it magically becomes a standard. sigh By the way, the IBM's DB2 is where SQL more or less was born. -- ----------------------------------------------------------------------------- | Georg S. Nikodym - (416) 442-2238 | | | | Southam Business Information and Communications Group, Don Mills, Ontario | | gsn@sclcig.UUCP -or- ...!uunet!attcan!telly!moore!sclcig!gsn | | | | "The floggings will continue until morale improves" -Jose Castel-Branco | -----------------------------------------------------------------------------
jkrueger@dgis.dtic.dla.mil (Jon) (07/08/90)
ajayshah@aludra.usc.edu (Ajay Shah) writes: >I've tried writing SQL queries and found it to be >tremendously irritating, mainly because it's nonprocedural. SQL isn't the problem here. Query languages are generally nonprocedural by design; if you don't like it, don't use them. >Now i'm sure 99% of the programmers of the world prefer >thinking procedural programming languages over >nonprocedural ones. And no one is forcing them to do otherwise. But if we have to pay for their lower productivity and live with their bugs, we may choose to engage that 1% instead. >I'm also a sufficiently fluent HLL >programmer to be certain it's more painful generating SQL >that it would be generating a procedural query language. Again, no one is forcing you to do otherwise. But perhaps you could give us an example here? >I'm also nearly certain optimising the speed of query would >be easier with a procedural query language. Only nearly certain? Good; it will surprise you what a good query optimizer will do. But all these arguments have been heard before. Last time I heard them it was that no compiler could beat the power, efficiency, and total flexibility of assembly language. Still want to argue that one? Also remember there's only one true measure of performance, it's the time from when you put the question until the time you get the answer, including all time you spend with the computer, whether you call it programming or waiting for a suboptimal program to complete. Using that metric I wouldn't care to race on the side of the custom coders. >So why is SQL defined the way it is? Again, SQL isn't the problem here. You have a problem with a large set of languages and forms, from query languages to logic programming. >Is it supposed to be some kind of standard which imposes >restrictions on the internal organisation of a RDBMS, so >that no "real-life" queries would use SQL? Or is it just a >rotten way of writing queries which somehow happened to >become a standard? Yes, no, yes, and not in the way you mean. But see above. >Are there any prominent standards for procedural queries on >relational databases? As many as you like :-) >Is SQL a portable standard: i.e., >can one expect to be able to blindly take a SQL script >written with one RDB (say, Unify) and make it work with >another (say, Oracle). No. >If so, then does that not reduce >the major RDB alternatives (Unify, Ingress, Oracle, etc) to >pretty generic alternatives (they all become SQL engines)? Different application development, user interface specification, dialog management, data type definition, database design, security standards and practices, network and distributed access, database management, archival and backup, checkpointing and audit, and maintenance, upgrade, and porting tools distinguish otherwise identical SQL engines, like unto night is distinguished from day. >In that case, what is it that differentiates two vendors? Some supply more and better tools. >I'd use Unix facilities for file-handling and backups etc, >anyway, so *if* SQL is totally portable and a 100% standard >then I wouldn't care about which RDB I used. You got one file per tuple? You mind taking the database down for backups? You mind not being able to assure recovery? -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Drop in next time you're in the tri-planet area!
mao@eden (Mike Olson) (07/09/90)
In <10632@chaph.usc.edu>, ajayshah@aludra.usc.edu (Ajay Shah) writes: > I've tried writing SQL queries and found it to be > tremendously irritating, mainly because it's nonprocedural. > ... > I'm also nearly certain optimising the speed of query would > be easier with a procedural query language. > > So why is SQL defined the way it is? this question will generate terabytes of traffic in the newsgroup; jon kreuger already responded, and presented several points well. as an internals type, i have a few things to add. in order for you to specify a procedural query, you need to know the layout of data on the disk, and you must be able to deal with all data types that appear in the data set you're working on. in addition, any changes to the information on disk -- what's stored, or how it's stored -- is going to force you to reformulate your procedural query. in order for you to specify an efficient procedural query, you need to know what indices exist on attributes in your tables, how selective they are, whether there's any ordering in the base tables you can exploit, whether caching results is likely to prove beneficial given the history and likely future course of execution, and eighty-seven pounds of other stuff that you probably don't want to think about. and if you do think about it, i can come along fifteen minutes later, add or delete an index, and send you into a screaming rage as you try to deal with the new schema. the reason that nonprocedural languages are attractive is precisely because they *are* nonprocedural. although i'm not crazy about sql, i do believe that nonprocedural query languages are superior to procedural ones for ad-hoc relational database access. programmers can be arbitrarily smart, but there's no way that they can generate good query plans as quickly as the query optimizer for a good database engine can, from a nonprocedural query spec. you will probably find that, with practice, formulating queries in sql gets easier. mike olson postgres research group uc berkeley mao@postgres.berkeley.edu
ghm@ccadfa.adfa.oz.au (Geoff Miller) (07/09/90)
mao@eden (Mike Olson) writes: >In <10632@chaph.usc.edu>, ajayshah@aludra.usc.edu (Ajay Shah) writes: >> I've tried writing SQL queries and found it to be >> tremendously irritating, mainly because it's nonprocedural. >> ... >the reason that nonprocedural languages are attractive is precisely because >they *are* nonprocedural. although i'm not crazy about sql, i do believe that >nonprocedural query languages are superior to procedural ones for ad-hoc >relational database access. programmers can be arbitrarily smart, but there's >no way that they can generate good query plans as quickly as the query >optimizer for a good database engine can, from a nonprocedural query spec. And the non-procedural query language can be used much more easily by a non-programmer. Sure, if you know that the same query will be run repeatedly it may be quicker to implement it in a small program, or simply incorporate it into a menu-driven system so the user has less chance of getting it wrong, but there will always be the odd ad-hoc query that you didn't allow for. I guess most of us who use the net are experienced programmers, so the procedural approach comes naturally to us *now*. What you have to remember is that there is a growing number of users who are demanding direct access to their data and are not prepared to wait while their request is filtered through the programming priesthood. SQL and similar non-procedural languages provide a means whereby these users can access their data quickly. Geoff Miller ghm@cc.adfa.oz.au
davidm@uunet.UU.NET (David S. Masterson) (07/13/90)
In article <1990Jul8.034532.14777@sclcig.uucp> gsn@sclcig.uucp (Georg Nikodym) writes: In article <10632@chaph.usc.edu> ajayshah@aludra.usc.edu (Ajay Shah) writes: > So why is SQL defined the way it is? That's the IBM way, make something really ugly, terrible and cumbersome and it magically becomes a standard. sigh By the way, the IBM's DB2 is where SQL more or less was born. Well, picking on the way IBM does (or doesn't do) things can become a national pasttime. If you want some fairly complete reasons for hating SQL (along with the current, general state of relational database systems), check out the new book by Dr. Codd entitled "The Relational Model for Database Management Version 2". Be warned, though, a lot of it reads like Dr. Codd has had his feelings hurt by the lack of enthusiam within the community for his relational model ideals. -- =================================================================== David Masterson Consilium, Inc. uunet!cimshop!davidm Mt. View, CA 94043 =================================================================== "If someone thinks they know what I said, then I didn't say it!"
tom@nw.stl.stc.co.uk (Tom Thomson) (07/19/90)
In article <1990Jul8.034532.14777@sclcig.uucp> gsn@sclcig.uucp (Georg Nikodym) writes: > >That's the IBM way, make something really ugly, terrible and cumbersome >and it magically becomes a standard. sigh You shouldn't blame IBM for this one. A very large part of what's wrong with SQL is a result of the american standardisation process: you could summarise it as "even if that's the best way to do that, we mustn't do it that way as it will give XXX too big a competitive advantage". So blame ANSI for this one, not IBM. (note: European standards bodies suffer from this too, it's not just an ANSI problem. The classical example is the ISO standard transport protocol, which simply incorporates five different protocols [derived from 3 different approaches to the problem the standard addresses: so perhaps it's just 3 unrelated protocols, of which 2 have 2 mutually incompatible variants] and says take your pick - - -omitting any one would have prevented the publication of the standard by ensuring a large NO vote from its supporters.) IBM gave us a big advance in query languages; ANSI emasculated it. Tom Thomson [tom@nw.stl.stc.co.uk [Note: above represents my views, not those of my employer. I still think SQL (even the IBM version) is pretty awful. I have no connection with IBM.