SQL
in [OOP]
|
From: H. S. Lahman on 11 Jan 2006 11:21 Responding to Priya1 wrote: > What are the advantages os SQL over third generation Language? Sounds like another homework problem. SQL /is/ a 3GL. It is just highly specialized to support Data Modeling. If you want to model data and access it in a very generic fashion, then SQL is pretty much the only game in town. OTOH, if you are solving problems where persistence access is of secondary concern (i.e., applications beyond RAD CRUD/USER pipelines), then SQL is not a very good language to use because it doesn't handle dynamic issues well, doesn't support abstraction, it is not very maintainable, and it is just plain ugly. So in that case one should limit SQL usage to the implementation of a subsystem whose mission is to actually talk to the persistence mechanisms. ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
From: Mikito Harakiri on 11 Jan 2006 13:32 topmind wrote: > Mikito Harakiri wrote: > > priya1 wrote: > > > What are the advantages os SQL over third generation Language? > > > > Here are couple of paragraphs from preface of my advanced SQL > > programming book (due in may): > > > > <quote> > > SQL is a very successful language. This might be surprising to a > > newcomer who generally find SQL a little bit old fashioned compared to > > "modern" programming languages. It's almost as old as COBOL and it > > looks like FORTRAN, > > > SQL is about 15 years younger than COBOL, so "almost as old" is > misleading. Wikipedia: "COBOL was initially created in 1959" Codd's seminal paper "A Relational Model of Data for Large Shared Data Banks" is dated 1970. > What I don't get is why other relational languages don't make a run at > SQL? The only serious attempt is from the Date group (Tutorial D). (I > have also drafted a relational language myself, tentatively called > SMEQL.) There was a discussion at /. Synopsis: "What about newer relational languages? Why, for example, the latest and greatest Tutorial D didn't take over the world? It has improved notation, better NULL handling, and pure set semantics. This is not enough however; a New and Improved query language had better be leaps and bounds ahead, not just simpler to type."
From: Mikito Harakiri on 11 Jan 2006 16:39 Mikito Harakiri wrote: It's almost as old as COBOL and it > > > looks like FORTRAN, > > > > > > SQL is about 15 years younger than COBOL, so "almost as old" is > > misleading. > > Wikipedia: "COBOL was initially created in 1959" > Codd's seminal paper "A Relational Model of Data for Large Shared Data > Banks" is dated 1970. Well, the time precedence typo in your message aside, the 15 years gap is just about right. Perhaps, the better phrasing is: "It's almost as old as C (which spawned at least 3 newer generation languages) and it looks like COBOL, why isn't it obsolete yet?" Thank you for correction.
From: topmind on 12 Jan 2006 21:20 Mikito Harakiri wrote: > topmind wrote: > > Mikito Harakiri wrote: > > > priya1 wrote: > > > > What are the advantages os SQL over third generation Language? > > > > > > Here are couple of paragraphs from preface of my advanced SQL > > > programming book (due in may): > > > > > > <quote> > > > SQL is a very successful language. This might be surprising to a > > > newcomer who generally find SQL a little bit old fashioned compared to > > > "modern" programming languages. It's almost as old as COBOL and it > > > looks like FORTRAN, > > > > > > SQL is about 15 years younger than COBOL, so "almost as old" is > > misleading. > > Wikipedia: "COBOL was initially created in 1959" > Codd's seminal paper "A Relational Model of Data for Large Shared Data > Banks" is dated 1970. Codd did *not* create SQL, contrary to popular belief. Early test relational languages were more math-like. IBM later decided to COBOLify them, allegedly thinking that made it more palattable to managers (Dilbertian PHB view). > > > What I don't get is why other relational languages don't make a run at > > SQL? The only serious attempt is from the Date group (Tutorial D). (I > > have also drafted a relational language myself, tentatively called > > SMEQL.) > > There was a discussion at /. Synopsis: > "What about newer relational languages? Why, for example, the latest > and greatest Tutorial D didn't take over the world? It has improved > notation, better NULL handling, and pure set semantics. This is not > enough however; a New and Improved query language had better be leaps > and bounds ahead, not just simpler to type." I generally agree, but for those who do queries all day a somewhat better language would be worth it. I think there is room for a good "mathy" standard for power query worriors, and the more verbose English-like SQL for occasional users. Actually if SQL standard(s) added named virtual views that would be a huuuuge leap forword for more complicated queries. That way you can name sub-queries instead of having to nest them. Big SQL is too damned nesty, leading to run-on sentences. But there are things that SQL is still crappy at even with that fix. For example, often you want to say "get all columns except these few". In SQL you have to name them all, minus the excluded ones. SMEQL allows one to use the query language's built-in set tools to "calculate" column lists so that you could specify all colums minus another list. For stuff like this, the "ME" stands for "meta enabled". -T-
From: topmind on 13 Jan 2006 21:52
H. S. Lahman wrote: > Responding to Priya1 wrote: > > > What are the advantages os SQL over third generation Language? > > Sounds like another homework problem. > > SQL /is/ a 3GL. Depends on how you define GL's. What do you consider an example of a 4GL? > It is just highly specialized to support Data Modeling. > If you want to model data and access it in a very generic fashion, > then SQL is pretty much the only game in town. > > OTOH, if you are solving problems where persistence access is of > secondary concern (i.e., applications beyond RAD CRUD/USER pipelines), > then SQL is not a very good language to use because it doesn't handle > dynamic issues well, doesn't support abstraction, it is not very > maintainable, and it is just plain ugly. Are you talking about SQL specificly, or relational in general? "Doesn't support abstraction" is a rather sweeping claim. I am trying to see if there is likely to be yet another OO-vs-Relational battle breaking out here. > So in that case one should > limit SQL usage to the implementation of a subsystem whose mission is to > actually talk to the persistence mechanisms. > > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman -T- |