SQL
in [OOP]
|
From: JXStern on 15 Jan 2006 12:58 On 10 Jan 2006 19:08:10 -0800, "topmind" <topmind(a)technologist.com> wrote: >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.) > >People make a jillion procedural and OOP languages, but there are only >2 or so SQL competitors, and they are in draft mode for the most part. >Why the big diff? I can answer that. It's the cost of entry. Any schmuck can define a new scripting language and throw something out there in a matter of weeks, and it will compete with other scripting languages on a more or less equal basis. For any database language, you need an engine, which is not rocket science but is a solid piece of work to code, and besides a simple parser you NEED an optimizer, which major 3GL compilers have, but scripting languages don't. I've recently been doing a lot of database optimization work, and what that turns out to be (on SQLServer) is understanding how its optimizer works, and finding when it breaks down (which can be very often under certain scenarios) - and then getting it back into proper operation. MySQL has never been a real competitor because it lacked the optimization, much less the language features, of larger engines. That said, I was also just ruminating on how ambiguous SQL is from a semantic perspective, for starters in that joins may either expand or constrain a selection. If the intent of query statements was more evident, it would be easier to optimize properly. I was just Googling up what I could of QUEL, and wondering what I would do for a Josh's Own Version of a Structured Query Language. So, yes, I second your question, why more of this hasn't been done, by Oracle and Microsoft their own selves, if nobody else (well, Microsoft isn't exactly known for such innovations, and their engine is not open to modification, and Oracle is fat and happy with PL/SQL and Java applets). Maybe somebody can branch off MySQL in such a direction. Did Stonebreaker ever spend much time on the language side? Not that I know of. So, back to OP, I'd say the difference between SQL and 3GLs is in the implied execution engines, which implies a different semantic approach to the entire topic of computation. But if that was a homework question, all they're looking for is the word "nonprocedural", not that I'd call that an "advantage" as such, see parallel post. J.
From: Patrick May on 15 Jan 2006 13:13 "H. S. Lahman" <h.lahman(a)verizon.net> writes: > Unfortunately, I agree with May . . . . "Unfortunately"? I thought only my wife found something inherently objectionable about agreeing with me. Regards, 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: topmind on 15 Jan 2006 15:30 Patrick May wrote: > "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. But how are tables less close to the domain than classes, methods, and attributes? (I agree that some of the behavior side is not something to be done on the DB, but that is simply a partitioning of specialties issue.) > > > 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? Perhaps I will return to it later because it is somewhat off-topic. > > > 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. This is not the censuses in the OO community. > > > > > 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. Agreed. I never said that biz apps were only CRUD screens/reports. I would note that a lot of the issues you mentioned, such as performance, scalability, resiliency, and recoverability can be obtained by purchasing a "big-iron" RDBMS such as Oracle or DB2. The configuration and management of those issues is then almost a commodity skill and not as tied to the domain as a roll-your-own solution would be (which OO'ers tend to do). "Security" is mostly just massive ACL tables. > > [ . . . ] > > 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. Again, I have yet to see an objective or even semi-objective way to measure "complexity". Again, the basic concepts of CRUD are easier to learn than most other domains or problems, but that does not mean that the implementation and maintainence of related apps is simple. For lack of a better metric, I propose lines of code (LOC) for now as our metric for complexity. "Everybody just knows it" is not good enough, and questionable. CRUD apps are not less lines of code (although the skill of the developer can make a huge difference). Can you make an argument for something being lots of LOC without being "complex" (beyond learning the domain)? If not, then you are probably stuck using LOC here. (And I don't mean bad use of code, such as hard-wiring the database values into long case statements.) > > Sincerely, > > Patrick > -T-
From: topmind on 15 Jan 2006 16:03 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? > > The point is that there are alternative /implementations/ for > persistence to RDBs in the computing space. SQL has already made that > implementation choice. SQL is not an implementation. What is the difference between locking yourself to SQL instead of locking yourself to Java? If you want open-source, then go with PostgreSQL. What is the diff? Java ain't no universal language either. > > >>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. For the zillionth time, RDBMS are far more than just "persistence". Some newer RDBMS don't even have to touch the disk. DB's provide these services: # Persistence # High-level (English or math-like) query languages or query ability # metadata repository # State management # Multi-user contention management and concurrency (locks, transactions, rollbacks, etc.) # Backup and replication of data # Access security # Data computation/processing (such as aggregation and cross-referencing) # Data rule enforcement or validation # Data export and import utilities # Multi-language and multi-application data sharing # Data change and access logging # Automated "result path" optimization (user focuses on what, not on how) You just don't get these with flat files unless you program them in yourself, which is called "reinventing the DB wheel". Currency, joins, and aggregation alone require a lot of coding. "Persistence" alone does not cover that. Concurrency, joins, and aggregation are perhaps even orthogonal to "persistence". Let's see clay tablets do a join. Have an elephant sit on them? Be my guest, just tell me when you find all the data and let's compare to the results to even a CPM-era desktop DB. > 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. So being married to Java is better than being married to SQL? Java does not even have many of the features mentioned above. > > >>>>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. Well, I will agree that relational languages may not be suitable to *every* domain, but that does not mean they are not general purpose. There is no "general purpose" tool/language that is ideal for everything. Thus, "everything" is an unreachable goal for any tool/lang. Many things are "semi-general-purpose" and DB's are one of them. > > >>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. I disagree. A large part of *most* apps I have seen involves database-oriented stuff. P. May mentioned security. Security can be viewed as a dealing with large ACL tables. Most algorithms can be reduced to mostly DB-oriented operations. I had to build a 3D graphics system in college, and most of it could be reduced to DB-operations: having "parts" reference each other in many-to-many tables, transformation steps tracking, looking up polygons, cross-referencing those polygons with their "parent part", storing scan-lines for later inspection, etc. I will agree that DB's are not (currently) fast at such, but still from a logical perspective the operations were essentially DB-oriented. (Because I couldn't use a DB, I ended up reinventing a lot of DB idioms and it was not very fun.) A compiler/interpreter is the same way: a DB would make it simpler to implement, especially fancy interactive debuggers, but performance/RAM issues make it not practical. Thus, one spends a lot of time coding array and pointer hopping to look stuff up, count things, etc. Most of it is just tracking and associating "stuff". > > Unfortunately, I agree with May that the rest of the paragraph makes no > sense; it just seems to be your personal jargon and mantras. If May said anything else, we should check his tempurature. He has never been friendly to me or my ideas. A polite person would simply ask for clarification rather than label it "jargon or mantras". You wouldn't do that to your boss, would you? > > >>>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. Real-time and embedded? I think they are going away from it because of auto garbage collection, DB's, etc. -- stuff that RT/E avoids. > > 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. Please clarify. If a process was "not taxing", then you are simply given more duties and projects to work on. Management loads you up based on your productivity and work-load. > > 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.) Unfortunately good RAD/IDE tools have yet to arrive for web-based apps, and we're stuck futzing with the limits of low-level HTTP issues. > > >>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. You are so cute when you paint me as bad, manipulative, and evil. > > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman -T-
From: H. S. Lahman on 16 Jan 2006 10:52
Responding to May... >>Unfortunately, I agree with May . . . . > > > "Unfortunately"? I thought only my wife found something > inherently objectionable about agreeing with me. My intent was that the 'unfortunate' referred to feeling that what Jacobs said was gibberish. I was just trying to take the high road by taking the edge off. ************* 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 |