SQL
in [OOP]
|
From: H. S. Lahman on 14 Jan 2006 11:31 Responding to Jacobs... >>SQL /is/ a 3GL. > > > > Depends on how you define GL's. What do you consider an example of a > 4GL? There are a number of definitions. The one I find most useful is that a 4GL language solution is independent of particular computing environment implementations. IOW, the 4GL expresses solutions purely in problem space terms. That let's SQL out because it depends upon the specific RDB implementation of the RDM. UML with a compliant AAL is an example of a 4GL. If I build an OOA model for, say, a POS Order Entry System, that model can be unambiguously implemented without change either manually as a print mail order catalogue or as software for a browser-based 'net application. The fundamental processing logic of catalogue organization and order entry is expressed the same way regardless of the implementation context. >>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. SQL specifically. IMO it isn't a very good language even for relational. It survives because of the huge volumes of legacy code around. Note that when you do P/R you don't program solely in SQL; you just use SQL to talk to the RDB. [One could argue that "bad" languages are/were very successful /because/ they were inelegant. For example, the inelegant verbosity and tedious simplicity of COBOL dominated software development for three decades because it worked well under the constraints of practical development.] SQL does support abstraction in the sense that it abstracts the RDB implementation. However, here I was referring to problem space abstraction. > I am trying to see if there is likely to be yet another > OO-vs-Relational battle breaking out here. Only indirectly. CRUD/USER pipeline applications have architectures and infrastructures that are hard-wired around the RDB implementation of the RDM. That is usually not the case for OO applications solving more complex problems. Note that UML static diagrams also implement the RDM but they do so in a very different way than the RDBs do. [That difference in the way the RDM is applied is one reason why OOA/D objects in a non-CRUD/USER application model will often not map 1:1 with the RDB Data Model's tables. So in such applications one tends to isolate RDB access in a single subsystem so that the conversion rules can be encapsulated in one place. (The fact that both model the same problem space and both employ the RDM in some fashion ensures that there will be unambiguous conversion rules.)] ************* 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: topmind on 14 Jan 2006 14:56 H. S. Lahman wrote: > Responding to Jacobs... > > >>SQL /is/ a 3GL. > > > > > > > > Depends on how you define GL's. What do you consider an example of a > > 4GL? > > There are a number of definitions. The one I find most useful is that a > 4GL language solution is independent of particular computing environment > implementations. IOW, the 4GL expresses solutions purely in problem > space terms. That let's SQL out because it depends upon the specific > RDB implementation of the RDM. What you are talking about is not a limit, but a "problem" of choice. If the *only* RDBMS on the planet was say PostgreSql, then such a complaint would not exist anymore than there being only one implementation of say a Python interpreter. Nobody ever claimed that Python was a lessor generation language because there was only one implementation. One can run Postgre on Unix, Macs (IIRC), PC's, etc. I would note. Why demote the rank of something simply because there are choices? > > UML with a compliant AAL is an example of a 4GL. If I build an OOA > model for, say, a POS Order Entry System, that model can be > unambiguously implemented without change either manually as a print mail > order catalogue or as software for a browser-based 'net application. > The fundamental processing logic of catalogue organization and order > entry is expressed the same way regardless of the implementation context. And if other people/vendors made their own flavor of this tool with differences between the implimentation, then it would be in the same boat. Why should implementation A1 and A2 demote the "generation" ranking of A? > > >>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. > > SQL specifically. IMO it isn't a very good language even for > relational. I agree that it needs improvement/overhaul. However, it is still a powerful tool even without fixes. > It survives because of the huge volumes of legacy code > around. Note that when you do P/R you don't program solely in SQL; you > just use SQL to talk to the RDB. That is Divide and Conquer, letting code do what it does best and the DB doing what it does best. > > [One could argue that "bad" languages are/were very successful /because/ > they were inelegant. For example, the inelegant verbosity and tedious > simplicity of COBOL dominated software development for three decades > because it worked well under the constraints of practical development.] IMO COBOL survived largely because it was tuned to the domain, not because of its English-like syntax. > > SQL does support abstraction in the sense that it abstracts the RDB > implementation. However, here I was referring to problem space abstraction. This depends on how one defines "problem space abstraction". The OO view of PSA is kinda lame if you ask me. It does not factor out common "database verbs" into a single tool or convention, but reinvents it over and over for many classes. Repetative SET/GET syndrome is an example of this poor pattern factoring. OO'ers often don't see this ugly ugly duplication of concept. > > > I am trying to see if there is likely to be yet another > > OO-vs-Relational battle breaking out here. > > Only indirectly. CRUD/USER pipeline applications have architectures and > infrastructures that are hard-wired around the RDB implementation of the > RDM. That is usually not the case for OO applications solving more > complex problems. We have been over this already. There is no objective measurement that says biz apps are "simpler". I will agree that it is usually easier to learn business domains than say 3D graphics or rocket science, but learning the domain and implementing apps for it are two different things. You are participating in Domain Bigotry here. > Note that UML static diagrams also implement the RDM > but they do so in a very different way than the RDBs do. UML takes us back to the navigational/CODYSAL pointer/path hell that proved a mess in the 60's and 70's. UML and OO is the structural GO TO of the modern age. > > [That difference in the way the RDM is applied is one reason why OOA/D > objects in a non-CRUD/USER application model will often not map 1:1 with > the RDB Data Model's tables. So in such applications one tends to > isolate RDB access in a single subsystem so that the conversion rules > can be encapsulated in one place. (The fact that both model the same > problem space and both employ the RDM in some fashion ensures that there > will be unambiguous conversion rules.)] I will agree that "local views" are often needed. However, I don't see how OO helps with this. (Except perhaps that current languages usually don't support local table manipulation; but that is a fault of implimentors, not P/R. It used to be common until the OO hype made vendors yank it out, becoming a self-fullfilling prophecy.) > > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman -T-
From: Patrick May on 15 Jan 2006 08:50 "topmind" <topmind(a)technologist.com> writes: > H. S. Lahman wrote: > > SQL does support abstraction in the sense that it abstracts the > > RDB implementation. However, here I was referring to problem > > space abstraction. > > This depends on how one defines "problem space abstraction". "Problem space abstraction" typically refers to a concept from the domain for which the software system is being developed, e.g. Customer, Sales Order, Network Element, Product, etc. This is distinguished from "solution space abstractions" such as tables, rows, columns, keys, pointers, functions, and so on. This isn't a point of contention among experienced software developers. > The OO view of PSA is kinda lame if you ask me. It does not factor > out common "database verbs" into a single tool or convention, but > reinvents it over and over for many classes. I can't make sense of this assertion as stated. Could you provide examples? > Repetative SET/GET syndrome is an example of this poor pattern > factoring. Proliferation of get/set methods is a code smell. Immutable objects are to be preferred. > > > I am trying to see if there is likely to be yet another > > > OO-vs-Relational battle breaking out here. > > > > Only indirectly. CRUD/USER pipeline applications have > > architectures and infrastructures that are hard-wired around the > > RDB implementation of the RDM. That is usually not the case for > > OO applications solving more complex problems. > > We have been over this already. There is no objective measurement > that says biz apps are "simpler". Mr. Lahman does not appear to be discussing particular domains. CRUD/USER applications appear in most domains, after all even laboratories developing advanced nanotechnology technology need to be able to enter data and generate reports. Correspondingly, not all business applications are limited to CRUD/USER behavior. As an example, I'm currently working on a set of systems for a mobile telephony operator. The systems are definitely providing business functionality (provisioning, billing, fraud detection, etc.) but the components are distributed over a large number of physical machines, interacting with numerous vendors and partners, dealing with multiple legacy systems, and supporting complex business rules. Performance, scalability, resiliency, security, recoverability, and other non-functional requirements are at least as difficult to address as the core business requirements. [ . . . ] > You are participating in Domain Bigotry here. No, he is simply stating the obvious: CRUD/USER applications are not particularly complex, especially when compared with other software systems. Sincerely, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | The experts in large scale distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, CORBA, UML)
From: H. S. Lahman on 15 Jan 2006 10:51 Responding to Jacobs... >>>>SQL /is/ a 3GL. >>> >>> >>> >>>Depends on how you define GL's. What do you consider an example of a >>>4GL? >> >>There are a number of definitions. The one I find most useful is that a >>4GL language solution is independent of particular computing environment >>implementations. IOW, the 4GL expresses solutions purely in problem >>space terms. That let's SQL out because it depends upon the specific >>RDB implementation of the RDM. > > > What you are talking about is not a limit, but a "problem" of choice. > If the *only* RDBMS on the planet was say PostgreSql, then such a > complaint would not exist anymore than there being only one > implementation of say a Python interpreter. Nobody ever claimed that > Python was a lessor generation language because there was only one > implementation. One can run Postgre on Unix, Macs (IIRC), PC's, etc. I > would note. > > Why demote the rank of something simply because there are choices? The point is that there are alternative /implementations/ for persistence to RDBs in the computing space. SQL has already made that implementation choice. >>UML with a compliant AAL is an example of a 4GL. If I build an OOA >>model for, say, a POS Order Entry System, that model can be >>unambiguously implemented without change either manually as a print mail >>order catalogue or as software for a browser-based 'net application. >>The fundamental processing logic of catalogue organization and order >>entry is expressed the same way regardless of the implementation context. > > > And if other people/vendors made their own flavor of this tool with > differences between the implimentation, then it would be in the same > boat. Why should implementation A1 and A2 demote the "generation" > ranking of A? It is not the same thing at all. The 4GL solution does not care if persistence is /implemented/ with RDBs, OODBs, flat files, paper files, or clay tablets. The 4GL solution is completely independent of those choices. SQL is completely dependent on an RDB implementation of persistence. IOW, SQL has already made the implementation choice. >>>>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. >> >>SQL specifically. IMO it isn't a very good language even for >>relational. > > > I agree that it needs improvement/overhaul. However, it is still a > powerful tool even without fixes. > > >>It survives because of the huge volumes of legacy code >>around. Note that when you do P/R you don't program solely in SQL; you >>just use SQL to talk to the RDB. > > > That is Divide and Conquer, letting code do what it does best and the > DB doing what it does best. It reflects the fact that SQL is not well suited to describing solution dynamics and general programming, which was my original assertion. >>SQL does support abstraction in the sense that it abstracts the RDB >>implementation. However, here I was referring to problem space abstraction. > > > This depends on how one defines "problem space abstraction". The OO > view of PSA is kinda lame if you ask me. It does not factor out common > "database verbs" into a single tool or convention, but reinvents it > over and over for many classes. Repetative SET/GET syndrome is an > example of this poor pattern factoring. OO'ers often don't see this > ugly ugly duplication of concept. I am talking about the abstracting the domain where the original problem exists rather than the computing domain where a software solution will be executed. SQL only abstracts a very narrow part of the computing domain. Unfortunately, I agree with May that the rest of the paragraph makes no sense; it just seems to be your personal jargon and mantras. >>>I am trying to see if there is likely to be yet another >>>OO-vs-Relational battle breaking out here. >> >>Only indirectly. CRUD/USER pipeline applications have architectures and >>infrastructures that are hard-wired around the RDB implementation of the >>RDM. That is usually not the case for OO applications solving more >>complex problems. > > > We have been over this already. There is no objective measurement that > says biz apps are "simpler". I will agree that it is usually easier to > learn business domains than say 3D graphics or rocket science, but > learning the domain and implementing apps for it are two different > things. > > You are participating in Domain Bigotry here. I never said business applications are simpler; I spent nearly a decade doing heavy duty business applications. I am also on record in this forum for saying several times that modern IT is beginning to look a lot like R-T/E. What I implied was that CRUD/USER applications tend to be not very complex. Report generation was never very taxing even back in the COBOL days, long before SQL, RDBs, or even the RDM. Substituting a GUI or browser UI for a printed report doesn't change the fundamental nature of the processing. Nonetheless USER/CRUD processing remains a substantial segment of IT processing, which is why RDBS and SQL are popular and RAD IDE automation was developed. (Note that RAD IDEs represent an early form of translation; it was just limited to the CRUD/USER niche.) >>Note that UML static diagrams also implement the RDM >>but they do so in a very different way than the RDBs do. > > > UML takes us back to the navigational/CODYSAL pointer/path hell that > proved a mess in the 60's and 70's. UML and OO is the structural GO TO > of the modern age. You keep trying but I'm still not biting. This is just another of your stock ploys to pull people's chains. You throw out a deliberately baseless and nonsensical assertion just to create emotional controversy to drag people down your anti-OO rabbit hole. ************* 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: JXStern on 15 Jan 2006 12:45
On 10 Jan 2006 09:42:00 -0800, "Mikito Harakiri" <mikharakiri_nospaum(a)yahoo.com> wrote: >Here are couple of paragraphs from preface of my advanced SQL >programming book (due in may): > ><quote> >SQL is a very successful language. Mostly as an insert into extended and as of yet non-standard versions from Oracle, Microsoft, and others. > This might be surprising to a >newcomer who generally find SQL a little bit old fashioned compared to >"modern" programming languages. Old-fashioned? Pure SQL is purely non-procedural, of which there is only a whiff in most modern languages, along the lines of mapping predicates, and that's hardly the same thing. But generally, richer predicates are what people add to simple 3GLs in order to make things SOTA. And SQL has some data-centric and semantic aspects which make it more of an early 5GL than anything yet out there and popular. > It's almost as old as COBOL and it >looks like FORTRAN, why isn't it obsolete yet? Same quibble as topmind, Cobol was used in 1959, SQL wasn't a practical language until, oh, the late 1980s. > Let assure the reader >that this appearance is misleading. Under the cover of sloppy and >archaic syntax we find a high abstraction language. I'm not sure you want to call a language "sloppy", the use might be sloppy but not the definition. Similarly, I'm not sure what "archaic syntax" could possibly mean, foresooth. >SQL programming is very unusual from procedural perspective: there is >no explicit flow control, no loops, and no variables either to apply >operations to, or to store intermediate results into. Without some variable extensions, it wouldn't be nearly as popular as it is today. And, you know, RPG was non-procedural before Fortran, in fact, plugboard programming was non-procedural before any high-level language! Cobol's report writer was non-procedural, I believe that goes back to the original definition - it was just refined RPG, after all! J. |