Re: OOP - a question about database access
Date: Tue, 4 Nov 2003 10:54:05 -0500
Message-ID: <k6KdnUriUJF8VjqiRVn-tg_at_golden.net>
"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message
news:e4330f45.0311040509.536447e1_at_posting.google.com...
> "H. S. Lahman" <h.lahman_at_verizon.net> wrote in message
news:<3FA6C49F.2020404_at_verizon.net>...
>
> I am crossposting from comp.objects to comp.database.theory because I
> would like to know also the opinion of the database folks.
>
> > > You probalby meant system instead of application.
> >
> > No, I meant /application/.
>
> Then you don't use the concepts properly. A GUI application is an
> application, a DBMS is another application, a data management
> specialized application. When they work together they form a system.
Alfredo, a dbms is a system. An SQL compiler is an application. A DBA tool is an application. A server console is an application.
> > > Persistence mechanisms are encapsulated by the DBMS, they are
> > > transparent to application developers.
> >
> > And how does the application solution access the DBMS? It has to pick a
> > mechanism like SQL, ODBC, an Oracle engine API, or whatever.
>
> You are calling mechanism to everything. SQL is not a mechanism, it is
> a language.
Everything is an object. Everything is a mechanism. Some folks prefer nebulous, ill-defined terminology because it strokes their egos: It enables them to think they are somehow superior when they understand what they are saying and nobody else does.
> The application GUI access the DBMS using a communication layer like
> ODBC, and using SQL as the communication language.
>
> GUI applications can be viewed as user friendly replacements for the
> DBMS consoles like Oracle's SQL Plus. In many cases, skilled users
> could use SQL Plus directly without the need of a taylored GUI
> application.
>
> > Both that
> > access and the DB schema needs to be decoupled from the application
> > solution for anything beyond RAD/USER pipeline applications.
>
> What is beyond RAD applications?
Or are we talking about the waterfall lifecycle? BAD? (brook application
development) CAD? (cataract application development) DAD? (ditch application development) LAD? (lake application development) MAD? (marsh application development) oh, no wait... it's obvious. To get beyond rapid applicationdevelopment, we use PAD! Portage application development!
> > >> That is, the problem solution does not care
> > >>if data is stored in an RDB, an OODB, flat files, or clay tablets.
The problem does not care what technology is used, but solutions most definitely do care. The solutions will depend very heavily on the technologies used.
> > > The problem solution does not care, but it is essential for the
> > > developers to know if the application is communicating with an RDBMS,
> > > a file processor, the OS file system etc.
> >
> > Only the developer providing the persistence access subsystem or layer
> > within the application needs to understand that stuff.
Define "developer". Is an end-user trying to create an ad-hoc report a developer? Everyone with a need to manage data needs to have some understanding of the data management system.
> The persistence subsystem is a part of the DBMS. Tables are persistent
> by default, but you can create temporary tables if you want.
>
> Of course the application developer must know if he is accessing to an
> SQL DBMS or to a mere disk file.
>
> > In particular,
> > whatever optimization is required to alleviate the persistence
> > bottleneck should be encapsulated away from the application solution.
>
> Yes, in the DBMS. The DBMS manages the physical persistence mechanisms
> like the hard disks.
This is the essense of physical independence.
> > Whoever is developing the solution to the business problem should focus
> > on that solution and be completely indifferent to data schemas, access
> > mechanisms, and I/O optimization.
>
> How can a data management solution be indiferent to the data
> representation manipulation model used?
Logical independence.
> > > The DBMS option is the only sensible if you need more than trivial
> > > data management capabilities.
> >
> > There is a whole world of applications beyond data display.
Agreed. Some applications exist to manipulate data without user intervention or external interfaces. How many applications neither manipulate nor present data?
> > >>One may use OO to implement the persistence access subsystem or layer,
> > >>but that view will be quite different than the business view.
But why the hell would anyone want to do anything so stupid?
> > > One may use OO to implement DBMSes. They must be general purpose
> > > DBMSes independent to any business problem.
> > >
> > > A good DBMS is expensive to build so in most cases you should use an
> > > existing one.
> >
> > Of course. But that doesn't mean the application needs to know which
> > one is being used or be affected if one changes one's mind later and
> > swaps in another.
I disagree. At some level, the application must absolutely know what technology it uses; otherwise, how the hell can it use it?
Everyone knows that abstraction is the key to effective software engineering. Using abstraction, one can limit the loci of effect of decisions one might reconsider. The question then becomes what is the best or most appropriate abstraction for a given purpose. Mr. Lahman seems unaware that the relational model is already a much higher-level abstraction and much more effective abstraction than any he is likely to invent using the primitive computational model of object oriented programming languages.
[snippage]
> Applications are replaced a lot more frequently than DBMSes.
Clear evidence of the ineffectiveness of most computational models based as most of them are on physical location of variables.
> If you have all your business logic in the centralized database, among
> many other advantages the applications are easier to replace.
If applications used higher-level abstractions, one would not have to replace them in the first place.
> > >>As a result one can abstract persistence mechanisms in terms
> > >>of paradigm invariants so that the classes are generic things like
> > >>Table, Schema, Row, and Field
> > >
> > > But it is not an issue for the information system developer because
> > > persistence is solved by the DBMS behind the scenes. In many cases it
> > > is undocumented.
> >
> > You seem to be including some sort of data warehousing or data mining
> > capabilities in your definition of DBMS that would allow abstract
> > queries.
>
> Data warehouses are only a special kind of databases.
Actually, I consider them only a part of a single database. When you think
of it, they are nothing more than snapshots.
> > For any DBMS I know of the schema had better be documented for
> > it to be directly accessible via SQL or whatever.
>
> I don't find sense here.
I agree. Basically, he is only stating the obvious that people have to communicate across distance and across time.
> > >>That application of invariants leads to things like JDBC/ODBC/SQL that
> > >>largely hide the mundane details of the mechanisms through automation.
> > >
> > > JDBC/ODBC are bridges between the application and the DBMS.
> > >
> > > SQL is the communication language between the application and the
> > > DBMS, and it is also the database design language. SQL has three
> > > parts: structural, integrity and manipulative.
> >
> > But they are all infrastructures provided to decouple the application
> > from direct communication with the DB engine.
>
> No, they are provided to communicate the presentation application with
> the DBMS.
I cannot make much sense of either of your positions above.
> > Using them restricts the
> > application to very particular and often proprietary modes of
> > persistence.
>
> DBMSes free application from the persistence issues. You simply must
> know that non temporary tables are persistent, and nothing else to
> say.
>
> But who cares about the physical format the DBMS use?
>
> If you talk about the communication layers like ODBC, ADO.NET, etc. It
> is rather easy to change one for the other. You only need to touch few
> code lines if any.
My first question is: Why are any of them necessary? Why do we persist in using such primitive computational models for application development in the first place?
> > My issue is about decoupling at a higher level than the DB engine. The
> > application solution needs to be independent of those assumptions.
>
> Independent to the data model?
>
> This is an absurd.
Higer level than predicate logic? That part is even more absurd.
> > One
> > does that by encapsulating those persistence mechanisms within a
> > subsystem or layer whose interface is independent of those mechanisms
> > (i.e., it manifests the problem solution's view of the data).
>
> Again, the DBMS does that. DBMS exposes only logical data structures.
> The physical persistence implementation and the physical data
> structures are hidden to the users.
>
> > One then
> > takes advantage of the automation providing such infrastructures by
> > using those sorts of paradigms /within/ the subsystem or layer.
What automation? Data independence?
What infrastructures? The DBMS?
What sorts of examples? ?
Lahman is talking nonsense.
> > >>Bottom line: starting out with an RDB as a central part of the
> > >>application
> > >
> > > System, not application.
> >
> > No, /application/. In my world a system is usually comprised of
> > multiple applications.
Exactly! Which is why Alfredo corrected you. The full system consists of a data management system and various applications. The dbms is a major sub-system--just as an operating system is a major sub-system, and each application's view of the database is only a tiny subset of each database's external representation.
> > >>is not going to be very helpful in understanding OO
What's to understand? A primitive computational model based on linear addressing coupled with dynamic dispatch to provide some rudimentary if clumsy abstraction? Received on Tue Nov 04 2003 - 16:54:05 CET