Re: SQL
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Wed, 18 Jan 2006 16:21:13 GMT
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@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- Follow-Ups:
- Re: SQL
- From: frebe
- Re: SQL
- References:
- Prev by Date: Re: Distributed inheritance
- Next by Date: Re: Distributed inheritance
- Previous by thread: Re: SQL
- Next by thread: Re: SQL
- Index(es):
Relevant Pages
|
