Re: OOP - a question about database access

From: Alfredo Novoa (alfredo_at_ncs.es)
Date: 11/02/03 

Date: 2 Nov 2003 04:58:45 -0800

"H. S. Lahman" <h.lahman@verizon.net> wrote in message news:<3FA3DEFB.3000502@verizon.net>...
> Responding to Tim...
>
> > If this is the wrong newsgroup, can someone please point me to the
> > correct one and disregard this.
>
> It's the right one, but the subject matter is too big for such a forum.

This is the right one but it is plenty of wrong people.
 
> That is especially
> easy to do if you jumop into OOP feet first because the OOPLs are all
> 3GLs so they are superficially procedural.

They are completely procedural.

> The biggest hurdle you face is to stop thinking in procedural terms.

I think you meant you need to stop thinking is the classic structured
terms.

If you want to do OO you must think in procedural terms because OO is
procedural.

> To
> do that and get the right mindset you need to understand OOA/D and that
> is not something on can do on a forum, given that there are literally
> hundreds of books expressing /different/ viewpoints written on the subject.

And most of that books are crap.

> > (I'm going to use Java in a JDeveloper environment and the database is
> > an MSAccess using a JDBC/ODBC bridge)
 
> In a properly partitioned application the persistence access
> mechanisms will be encapsulated so that they are transparent to the
> business problem solution.

You probalby meant system instead of application.

Persistence mechanisms are encapsulated by the DBMS, they are
transparent to application developers.

> That is, the problem solution does not care
> if data is stored in an RDB, an OODB, flat files, or clay tablets.

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.

The DBMS option is the only sensible if you need more than trivial
data management capabilities.

> One may use OO to implement the persistence access subsystem or layer,
> but that view will be quite different than the business view.

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.

> 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.

> 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.
 
> Bottom line: starting out with an RDB as a central part of the
> application

System, not application.

> is not going to be very helpful in understanding OO because
> a lot of the OO stuff will be hidden in the infrastructures like
> JDBC/ODBC and the tools the JDeveloper IDE provides.

Agreed, it would be better to try to develop a non data centric
system, like a game, a text processor, etc.

You typically need very little from OO in order to develop a business
information system: An SQL DBMS, a database design script and a client
app developed with a RAD, draging and dropping components in forms.

Alfredo

Relevant Pages

  • Re: OT Bull-fight avoidance (was: Why all the max length constraints?)
    ... DBMS, for example. ... The performance advantages of size constraints is ... developers have no choice ... often written prior to RM ideas getting incorporated into DBMS tools ...
    (comp.databases.theory)
  • Re: MV Keys
    ... is implemented by developers using an interface to a dbms. ... want dbms tool designers to suggest they will be making design ...
    (comp.databases.theory)
  • Re: choices regarding where to place code - in the database or middletier
    ... However, I believe there's a lot that the DBMS can't do well, ... >>and depending on the DBMS to do that stuff is also begging for problems, ... > NO middle-tier applications that couldn't be qualified ... especially when being used by inexperienced developers (and ...
    (comp.lang.java.databases)
  • Re: choices regarding where to place code - in the database or middletier
    ... However, I believe there's a lot that the DBMS can't do well, ... >>and depending on the DBMS to do that stuff is also begging for problems, ... > NO middle-tier applications that couldn't be qualified ... especially when being used by inexperienced developers (and ...
    (comp.lang.java.programmer)
  • Re: MV and SQL
    ... >> perform enquiries on it using the query language then, again, how the ... > Are you sure that a column in Pick is equivalent to a column in an SQL table ... If you had some bizarre need to do this in a Pick DBMS though, ... > Besides the query language of Pick what other ways do ...
    (comp.databases.theory)