SQL
in [OOP]
|
From: H. S. Lahman on 17 Jan 2006 13:55 Responding to Jacobs... >>>>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. >> >>Of course it's an implementation! It implements access to physical >>storage. > > > Just as Java implements access to physical RAM etc. Exactly. Java is a specific implementation of a 3GL. 3GL is the abstraction, Java is an implementation. Persistence access is the abstraction, SQL is an implementation. >> More important to the context here, that implementation is >>quite specific to one single paradigm for stored data. > > > Any language or API is pretty much going to target a specific paradigm > or two. I don't see any magic way around this, at least not that you > offer. UML is no different. 4GLs get around it because they are independent of /all/ computing space implementations. However, that's not the point. SQL is a 3GL but comparing it to Java is specious because Java is a general purpose 3GL. SQL represents a solution to persistence access that is designed around a particular model of persistence itself. So one can't even use it for general purpose access to persistence, much less general computing. >>Requirements -> 4GL -> 3GL -> Assembly -> machine code executable >> >>Everything on the left is a specification for what is immediately to its >>right. Similarly, everything to the right is a solution implementation >>for the specification on its immediate left. > > > Well that is a bit outdated. For one, the distinction between 4GL and > 3GL is fuzzy, and many compilers/interpreters don't use assembler. My 4GL definition isn't ambiguous, which is why I like it. Reviewers of OOA models have no difficulty recognizing implementation pollution. All compilers generate object code (relocatable Assembly). Most modern interpreters can produce storable bytecodes that are equivalent to Assembly from the VM's viewpoint. At run time one can view an interpreter as simply combining link and load functions that transform the bytecode to a machine instruction. But at some level the interpreter still has to understand that MUL,R1,R2 maps into bits. But you reverting to ploys again by deflecting. The context is specification vs. implementation, not how machine instructions are encoded. >>Go look at an SA/D Data Flow Diagram or a UML Activity Diagram. They >>express data store access at a high level of abstraction that is >>independent of the actual storage mechanism. SQL, ISAM, CODASYL, gets, >>or any other access mechanism, is then an implementation of that generic >>access specification. > > > SQL is independent of the "actual storage mechanism". It is an > interface. You may not like the interface, but that is another matter. > Repeat after me: "SQL is an interface, SQL is an interface, SQL is an > interface".... Try using SQL vs. flat files if you think it is independent of the actual storage mechanism. (Actually, you probably could if the flat files happened to be normalized to the RDM, but the SQL engine would be a doozy and would have to be tailored locally to the files.) SQL implements the RDB view of persistence and only the RDB view. > Plus, what such UML models often do is something like: > > method getGreenScarvesCostingLessThan100dollars(...) { > sql = "select * from products where prod='scarves' and color='green' > and price < 100" > return(foo.execute(sql)) > } > You simply wrap everything with long method names and call it > "abstraction" and pat yourselves on the back. However, it is not really > abstraction because often they are called from only ONE place. That > just contributes to code bloat and red-tape-code. Come on, Bryce, you know this ploy isn't going to work on me. B-) You create a non sequitur example that ignores OO relationship navigation principles and follow it up with a set of outlandish assertions about what OO is about. I refuse to join you in your rabbit hole. >>Java is certainly a general purpose 3GL. Like most 3GLs there are >>situations where there are better choices (e.g., lack of BCD arithmetic >>support makes it a poor choice for a General Ledger), but one could >>still use it in those situations. SQL, in contrast, is a niche language >>that just doesn't work for many situations outside its niche. > > > You could be right, but I have yet to see a good case outside of > split-second timing issues where there is a limit to the max allowed > response time. (This does not mean that rdbms are "slow", just less > predictable WRT response time.) > > If you can give an example outside of timing, please do. (I don't doubt > they exist, but I bet they are rarer than you imply. Some scientic > applications that use imaginary numbers and lots of calculus may also > fall outside.) Compute a logarithm. You can't hedge by dismissing "scientific" computations. Try doing forecasting in an inventory control system w/o "scientific" computations. Or try encoding the pattern recognition that the user of a CRUD/USER application applies to the presented data. The reality is that IT is now solving a bunch of problems that are computationally intensive. >>BTW, remember that I am a translationist. When I do a UML model, I >>don't care what language the transformation engine targets in the model >>implementation. (In fact, transformation engines for R-T/E typically >>target straight C from the OOA models for performance reasons.) Thus >>every 3GL (or Assembly) represents a viable alternative implementation >>of the notion of '3GL'. > > > > Well, UML *is* language. It is a visual language just like LabView is. Exactly. But solutions at the OOA level are 4GLs because they can be unambiguously implemented without change on any platform with any computing technologies. >>>>>>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". >> >>It is only if one refuses to manage complexity by separating logical >>concerns. > > > > "Separation" is generally irrelavent in cyber-land. It is a phsycial > concept, not a logical one. Perhaps you mean "isolatable", which can be > made to be dynamic, based on needs. "Isolatable" means that there is > enough info to produce a seperated *view* if and when needed. This is > the nice thing about DB's: you don't have to have One-and-only-one > separation/taxonomy up front. OO tends to want one-taxonomy-fits-all > and tries to find the One True Taxonomy, which is the fast train the > Messland. Use the virtual power of computers to compute as-need > groupings based on metadata. You know very well what I mean by 'separation of concerns' in a software context, so don't waste our time recasting it. Modularity has been a Good Practice since the late '50s. > This is also why UML sucks: Either you have a jillion diagrams of the > same thing in order to provide all the potential viewpoints that > different users and developers will need, or you have to force a > limited taxonomy on developers. UML does not provide this > virtualization capability. Again with the baseless assertions about what OO and OOA/D is about. I have to give you an A for persistence. B-)) >>Render unto the Disk generic static storage and render unto >>the Application context-dependent dynamics. >> >> * 1 >>[Context] ----------------- [Data] >> >> >> 1 * >>[Problem Solution] -------- [Data] >> >>The first view if the basis of the RDB paradigm -- generic storage of >>the same data for access by many different contexts. The second view is >>the one that is relevant for solving large problems -- access of data >>that is carefully tailored to the problem in hand. Storing and >>accessing data for many different contexts is a quite different problem >>than formatting and manipulating data to solve a specific problem. > > > > Again, DB's are not JUST for "storage". There are RAM-only RDBMS's. I agree they are used that for more, but it is not my problem if developers are determined to shoot themselves in the foot by bleeding cohesion all over the place. It is plain bad software practice to ignore logical modularity. As far as RAM RDBs go, for any large non-CRUD/USER problem I can formulate a solution (which doesn't have to be OO) that will beat your RAM RDB for performance, and often by integer factors. The RDB paradigm is not designed for context-dependent problem solving; it is designed for generic static data storage and access in a context-independent manner. Before you argue that the RAM RDB saves developer effort because it is largely reusable and that may be worth more than performance, I agree. But IME for /large/ non-CRUD/USER problems the computer is usually too small and performance is critical. [I could also argue that an OO solution will provide one with optimum performance "for free" because it falls out of basic OOA/D for the solution logic. IOW, one doesn't need that sort of reuse. But I won't argue that because that would be going down the rabbit hole. B-)] >>For a non-CRUD/USER application, SQL and the DBMS provide the first >>relationship while a persistence access subsystem provides the >>reformatting for the second relationship. > > > Reformatting? Please clarify. The solution needs a different view of the data that is tailored to the problem in hand. So the RDB view needs to be converted to the solution view (and vice versa). IOW, one needs to reformat the RDB data structures to the solution data structures. >>>>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.) >> >>When the only tool you have is a Hammer, then everything looks like a >>Nail. > > > > No, out of necessity I started my career without DB usage, and I never > want to return there. That's because you are in a CRUD/USER environment where P/R works quite well. Try a problem like allocating a fixed marketing budget to various national, state, and local media outlets in an optimal fashion for a Fortunate 500. >>Similarly, the OO paradigm allows one to solve those problems >>with quite different abstractions. >> >>[FYI, the most comprehensive book on building UML Class Diagrams is Leon >>Starr's "Executable UML: How to Build Class Models". In that book Leon >>repeatedly uses tables as analogues for validating class instances. In >>effect he is using them as a tool for normalization. But the >>identification of classes and properties is all done in a OO fashion via >>abstraction for the problem space. More important, the management of >>relationships and collaborations is very different than the RDB paradigm >>(e.g., one almost never selects from a collection of all instances and >>the notion of a multi-table join is virtually nonexistent in an OO >>application). IOW, there is a mapping to tables but the construction >>paradigm is not at all driven by a table view.] > > > > How is replacing a table view with a class view better? Sure, schema's > are messy at many shops, but given time the OO'ers will probably have > messy classes also. The same motiviation (or lack of) for slop is part > of human or management nature, not part of the paradigm. No paradigm > has been shown to FORCE good practices. At least relational provides > tools to keep schemas fairly clean (normalization rules). OO has no > decent normalization model, tacking on more and more classes and > methods like a shanty town living for the moment (out of necessity > perhaps). You never give up. It's not about 'better'. Nor is this subthread about OO vs. DBMSes. So I am not going to bite on these outrageous assertions either. No normalization model? Get serious. >> >><moved>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. >> >>Back in the '60s and early '70s writing COBOL code to extract data and >>format reports was a task given to the entry level programmers. That's >>where the USER acronym (Update, Sort, Extract, Report) came from. The >>stars went on to coding Payroll and Inventory Control where one had to >>encode business rules and policies to solve specific problems. > > > > Fine, show how OO better solves business rule management. (Many if not > most biz rules can be encoded as data, BTW, if you know how.) Why? That has nothing to do with whether a DBMS should execute dynamic business rules and policies. This isn't an OO vs. P/R discussion, much as you would like to make it so. >>It is only when the >>problem solution gets drawn into the software that one leaves the realm >>of CRUD/USER processing and thing start to get tricky. >> >> >>>>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? >> >>We've been here before. It's part of your shtick. You define your own >>terms, like 'noun-based' and 'verb-based', and then throw them out on >>the table so that your opponent sees them as non sequitors. You also >>keep throwing out the same slogans as your web site. > > > That is called "reuse". LOL. I assume you mean reuse of forensic ploys. >>They are part of >>the predictable collection of forensic ploys you use when debating OO >>people. It's all designed to have an emotional effect to put the >>opponent on tilt. >> >>You seem to get your amusement out of having OO people go bonkers. > > > > I will admit there is a certain satisfaction of using other people's > own logic against themselves, especially if they have insulted me > prior. That doesn't answer why you went to the trouble of creating an inflammatory website and have been here for years. A simple dislike of OO? I don't think so. How many converts have you made to justify your crusade? It just wouldn't be worth the effort of beating your head against the wall all these years. So you have to have some other reason. The only plausible reasons I see are Quixotic masochism or you enjoy pulling people's chains. As far as insulting you is concerned, what do you expect? You throw out inflammatory statements, especially misconceptions about what OO development is about, that are designed to drive anyone who understands OO up a tree. If I used my knowledge of OO and tried to design a website that would drive OO people to outrage, it would be your geocities website. It pushes all the buttons in admirable fashion. (That you can push all the right buttons is what makes me believe you actually understand a lot more about OO than you pretend; it would be difficult to be so inflammatory without that knowledge.) So I have to conclude it is intentional. When you jump up and down on the bellows long enough, you will get burned. >>Seeing how far down the rabbit hole you can drag them is a sport to you. >> You even keep trying to get me involved in such debates, even though I >>insist on not biting. Do you think that I haven't noticed that this >>subthread started off as a discussion about DBMS vs. application >>responsibilities but you keep trying to push it into an OO debate? The >>entire paragraph in question was a blatant attempt to deflect from the >>DBMS issues to OO issues. > > > > OO'ers in generally do not like RDBMS and would rather wrap them > with OO wrappers so that they don't have to deal with them directly. > But this is not abstraction, it is translating horizontally from what > you hate to what you like. In their head RDBMS are (incorrectly) viewed > as low-level > assembler-like tools. Still pushing for a change of venue. This subthread has nothing to do with OO development so I won't go there. >>BTW, I would and have said similar things to various bosses. >> > > > > I don't know whether to label that as brave or foolish. Indispensable works for me. B-) >>>You are so cute when you paint me as bad, manipulative, and evil. >> >>Not bad or evil, but definitely manipulative. You just find it amusing >>to pull people's chains and the OO community is providing plenty of soft >>targets. As I've said before, I think you are actually know a lot more >>about OO development than you let on and you are pretty clever about the >>way you tweak the OO people who engage with you. > > > > You are spreading falsehoods about RDBMS. They are NOT low-level. You > only treat them as low level. Where did I say that? I said that once one is out of the realm of CRUD/USER processing, /talking/ to persistence is a low level service _within the application_. How persistence is implemented outside the application is a whole other story. ************* 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: Daniel Parker on 17 Jan 2006 14:01 H. S. Lahman wrote: > Responding to Parker... > > >>Of course it's an implementation! It implements access to physical > >>storage. > > > > That literally doesn't make sense. It's like saying that a Java interface > > is an implementation because it implements access to the properties of a > > physical instantiation. > > You have to step up a level in abstraction. Imagine you are a code > generator and think of it in terms of invariants and problem space > abstraction. > > The invariant is that all physical storage needs to be accessed in some > manner. There are lots of ways to store data and lots of ways to > access. Therefore ISAM, SQL, CODSYL, and C's gets all represent > specific implementations of access to physical storage that resolve the > invariant. It's not SQL that's the implementation, even in this context; it's the driver that implements the connectivity to the data provider. Any data provider that is capable of supplying data in conformance with the SQL data model will do. A typical driver supports connectivity to a relational database, but it's common these days for middleware vendors to provide drivers that will adapt web service output to SQL, according to certain rules. You can get drivers that will adapt flat file content to SQL, XML to SQL, and dynamic content from a C++ application server to SQL. Why do vendors provide such things? Because SQL is a standard querying language that is widely supported by a whole host of tools, because it provides a standard interface to data that conforms to a particular data model. The physical origin of that data is irrelevent. It's not just a question of conveniencing users with a syntax that they already know; it's a question of supporting automatic binding and reusing exisiting tooling. In your code generator example, you could easily have multiple drivers supporting SQL that resolve against very different physical data sources. (Not to mention XQuery drivers that resolve against the same sources.) > > > > I think it's fair to say that SQL has, for all its faults, been enormously > > successful, to the tune of a multi-multi-billion dollar industry, and that > > the UML translationist approach has not. It's been over ten years since the > > translationist industry has claimed to have solved the problem of 100 > > percent translation, but where is it, it's niche, it's nowhere. Other > > technologies have arrived, e.g. the W3C XML stack and particularly XSLT > > transformation, that dwarf executable UML in application. Why do you think > > that is? What do you think it is about software development that makes > > executable UML marginal, and other technologies like SQL important? > > All the world loves a straight man. B-) > :-) > However, the big translation demo lies in CRUD/USER processing. > Any time one develops an application using a RAD IDE like Access or > Delphi one is essentially using translation. That's a multi-billion > dollar niche that has been around since the '80s.] Right, but Access doesn't do this with executable UML. I don't think Access would benefit from going in this direction. > A fourth reason is the lack of standardization. Until OMG's MDA effort > all translation tools were monolithic; modeling, code generation, > simulation, and testing were all done in the same tool with proprietary > repositories, AALs, and supporting tools. (Prior to UML, they each had > unique modeling notations as well.) That effectively marries the shop > to a specific vendor. In '95 Pathfinder was the first company to > provide plug & play tools that would work with other vendor's drawing > tools. MDA has changed that in the '00s so now plug & play is a reality. > I grant that we are moving towards a service based world, with graphical interfaces playing a role in the assembly and orchestration of services, but I see no evidence that the glue is going to be executable UML. I don't think that many people care about what the OMG is doing anymore. Events have overtaken them. I don't think MDA is very important. There are other evolving standards for plug and play. Regards, Daniel Parker
From: frebe on 18 Jan 2006 03:12 > H. S. Lahman wrote: > Exactly. Java is a specific implementation of a 3GL. 3GL is the > abstraction, Java is an implementation. Persistence access is the > abstraction, SQL is an implementation. In that case is OO design the abstraction and UML the implementation. > SQL represents a > solution to persistence access that is designed around a particular > model of persistence itself. Since when is the relational model a "model of persistence". Can you provide any pointer showing that the relational model is supposed to be a "persistence model". > Try using SQL vs. flat files if you think it is independent of the > actual storage mechanism. (Actually, you probably could if the flat > files happened to be normalized to the RDM, but the SQL engine would be > a doozy and would have to be tailored locally to the files.) SQL > implements the RDB view of persistence and only the RDB view. Yes, the files need to be normalized to the RDM but why do you make the conclusion that SQL needs a RDB? > Exactly. But solutions at the OOA level are 4GLs because they can be > unambiguously implemented without change on any platform with any > computing technologies. Sounds a little bit like Java and the JVM.... > As far as RAM RDBs go, for any large non-CRUD/USER problem I can > formulate a solution (which doesn't have to be OO) that will beat your > RAM RDB for performance, and often by integer factors. The RDB paradigm > is not designed for context-dependent problem solving; it is designed > for generic static data storage and access in a context-independent manner. For any problem I can formulate an C++ solution that will beat your Java solution for performance. But I will still continue to use Java... Fredrik Bertilsson http://butler.sourceforge.net
From: seanwinship on 18 Jan 2006 04:12 H. S. Lahman wrote: > Responding to Jacobs... > > You are so cute when you paint me as bad, manipulative, and evil. > > Not bad or evil, but definitely manipulative. You just find it amusing > to pull people's chains and the OO community is providing plenty of soft > targets. As I've said before, I think you are actually know a lot more > about OO development than you let on and you are pretty clever about the > way you tweak the OO people who engage with you. I think you give Bryce too much credit. He's proven himself more than willing to have long discussions on topics he demonstrably knows nothing about, consistently refusing to admit his ignorance or recognize when his feeble arguments have been demolished. For a good example of this, check out his recent participation in talk.origins. I started reading that group after the recent spill over into comp.object. It reminded me of a junior high school anti-drug class where a very intense DARE instructor told us about a sixteen year old kid who took PCP and picked a fight with a group of U.S. Marines. As he lay in the gutter with multiple broken bones, barely conscious and bleeding to death, he yelled out at the departing jarheads through shattered teeth "That's it, run away before I kick your asses again!" I can't imagine a better analogy for Bryce Jacobs on Usenet. Sean
From: H. S. Lahman on 18 Jan 2006 11:21
Responding to Frebe... >>Exactly. Java is a specific implementation of a 3GL. 3GL is the >>abstraction, Java is an implementation. Persistence access is the >>abstraction, SQL is an implementation. > > > In that case is OO design the abstraction and UML the implementation. Up to a point. UML is just a notation, not a design paradigm so it does not implement OOA/D. However, UML is just one of many OOA/D notations proposed, so it is an implementation of an OOA/D notation. Thus in OMG's MOF meta hierarchy UML is, indeed, and implementation and OMG describes it exactly that way. (In fact, OMG uses four levels of abstraction to describe the hierarchy of UML itself and three of those are implementations of the higher level meta-models.) >>SQL represents a >>solution to persistence access that is designed around a particular >>model of persistence itself. > > > Since when is the relational model a "model of persistence". Can you > provide any pointer showing that the relational model is supposed to be > a "persistence model". I didn't say that. The RDM is a model of static data so it can be applied to UML Class Diagrams as well. Note that I was careful to say that SQL is a solution to persistence /access/ when the data is represented in RDB form. As you have pointed out elsewhere one could create a RAM-based RDB and use SQL to access it with no persistence. >>Try using SQL vs. flat files if you think it is independent of the >>actual storage mechanism. (Actually, you probably could if the flat >>files happened to be normalized to the RDM, but the SQL engine would be >>a doozy and would have to be tailored locally to the files.) SQL >>implements the RDB view of persistence and only the RDB view. > > > Yes, the files need to be normalized to the RDM but why do you make the > conclusion that SQL needs a RDB? SQL requires the data to be in tables and tuples with embedded identity. The RDM, when applied in a broader context than Codd, does not require that. SQL also assumes a very specific paradigm for navigating table relationships. >>Exactly. But solutions at the OOA level are 4GLs because they can be >>unambiguously implemented without change on any platform with any >>computing technologies. > > > Sounds a little bit like Java and the JVM.... Not quite. Choosing Java is already an implementation decision in the computing environment. More important, one can't do a lot of useful stuff in a Java program without explicitly invoking particular computing space technologies technologies (XML, EJB, TCP/IP, etc.). That's because the level of abstraction of 3GLs is the same as those computing space technologies. >>As far as RAM RDBs go, for any large non-CRUD/USER problem I can >>formulate a solution (which doesn't have to be OO) that will beat your >>RAM RDB for performance, and often by integer factors. The RDB paradigm >>is not designed for context-dependent problem solving; it is designed >>for generic static data storage and access in a context-independent manner. > > > For any problem I can formulate an C++ solution that will beat your > Java solution for performance. But I will still continue to use Java... I can't buy the analogy. The analogy compares performance across different implementations of the same solution. My point here is that the solution itself is inappropriate, regardless of the language that it is implemented in. No matter what language you choose I can always provide an alternative /solution/ that will have better performance for a specific complex problem. ************* 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 |