Re: Relational model versus object model
From: Topmind (topmind_at_technologist.com)
Date: 02/24/04
- Next message: _ee_: "Rock Paper Scissors - dual dispatch"
- Previous message: Arkadiy Vertleyb: "Re: Too many features"
- In reply to: H. S. Lahman: "Re: Relational model versus object model"
- Next in thread: Alfredo Novoa: "Re: Relational model versus object model"
- Reply: Alfredo Novoa: "Re: Relational model versus object model"
- Reply: H. S. Lahman: "Re: Relational model versus object model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 23 Feb 2004 20:00:27 -0800
>
> >>As far as concurrency is concerned, the DBMS is the logical place to
> >>address that when there are multiple readers and writers of data. A
> >>particular application should not have to worry about what other
> >>applications are reading and writing the data. OTOH, the application
> >>may have its own set of concurrency problems that the DBMS has no
> >>business knowing about.
> >
> >
> > Examples would be helpful. Note that I am a proponent of
> > a "local" DBMS engine for stuff that does not belong in
> > the "formal" or "central" DBMS.
>
> I assume you mean examples of local concurrency. Your application is
> inventory control for a retail bricks & mortar business. It receives a
> message whenever a bar code is read at a register. Each reading
> initiates a thread. In a typical IC system that processing can be
> trivial (e.g., updating the DB) for some items and very complex (e.g.,
> forecasting, triggering orders, triggering warehouse deliveries, etc.)
> for others. For a big business one could be simultaneously processing
> 10K reads at any given time.
Are you raising a speed/performance claim? Are you suggesting that DB2
or Oracle croaks for large inventory tracking systems?
I would note that one may not have to launch a new thread for each
read. Each reading device could simply be using a polling loop.
Roughly like:
while (notShutDown) {
message = barCodeReader(...);
if (message['didRead']) {
processBarCodeScan(message);
} else {
sleep(milliseconds(10));
}
}
function processBarCodeScan(message) {
executeQuery("select * from inventory where itemID=$1",
message['barCodeNumber']);
....
}
>
> >>>>>* Multi-language and multi-application data sharing
> >>>>
> >>>>I didn't include this one because I don't know what it means. Sounds
> >>>>good, though.
> >>>
> >>>
> >>>Sharing information with multiple languages and applications
> >>>in a convenient, consistent way.
> >>
> >>NS,DT! That's exactly why we separate reading and writing data from
> >>business problem solutions. That portability is achieved by decoupling
> >>the DBMS from the specific business problems being solved. If the DBMS
> >>is decoupled from the problem solutions, it is also decoupled from the
> >>solution mechanisms.
> >
> >
> > Again you appear to be assuming that only persistence is being
> > considered.
>
> On the DB-side, Yes. If one doesn't do that and allows the DBMS to get
> hung up on business rules and policies, the data is no longer decoupled
> from its use. It's fundamental complexity management: divide and
> conquer by separating concerns.
Divide and conquer is what DB's are all about: Separate "data things"
from tasks. OO intermixes them and drags them both down to the lowest
common denominator. A hint that this is true is that class designs
tend to mirror ER layouts, creating a OnceAndOnlyOnce orange alert.
>
> >
> > I'll tell you what. I would like to see an OO API that does
> > all the above, and this includes inter-language info sharing.
>
> I have no idea what you are asking for. The decoupling occurs because
> all the DB holds is data. Data is already independent of application
> language or problem solutions. It only has storage semantics. The
> interpretation and use is all on the client side.
It is about MORE than just storage. If you are only using DB's to make
stuff come back after somebody pulls the plug on RAM, you are wasting
the DB.
>
> To put it another way, the relational data model's popularity exists
> because it allows one to describe just the intrinsic properties of data
> without the pollution of problem solution specializations. The
> Phoenicians did the same thing, albeit much less precisely, with
> cuneiform and clay tablets.
What? What are "solution specializations"? We need yet another
buzzword like holes in our heads. Schema designs *are* part of the
"solution space", "solution model", or whatever the h8ll you want to
call it.
>
> >
> > Most likely satisfying this request will result in the invention
> > of a database of some sort (or at least an interface to one).
> >
> >
> >>>>>Caching allows a lot of RDBMS work to be done in RAM.
> >>>>
> >>>>That isn't the problem. It's the searches and key comparisons required
> >>>>when identity and relationships are tied to embedded data values.
> >>>>That's fine for data management or even CRUD/USER pipeline applications
> >>>>but one doesn't want to solve complex business problems that way.
> >>>
> >>>
> >>>Please define/clarify "complex business problems".
> >>
> >>Problems where the Business layer processing is large compared to either
> >>the Presentation (UI) or the Data layers in a conventional layered
> >>model. IOW, applications that are not simple USER/CRUD pipelines
> >>between UI and DB.
> >
> >
> > For one, you seem to assume that CRUD applications are always
> > simple. If they were, they would be factored into an
> > off-the-shelf-box. (There are RAD tools that claim to do such,
> > but they rarely offer or facilitate the
> > long-term customization that many
> > businesses want.) But I will agree that business applications tend to
> > be "link bound" as opposed to "node-bound". This means that
> > the hardest part of "processing" is gathering information
> > for many peices and sources of data. In other words, the
> > gathering is usually the complexity bottleneck rather than the
> > raw processing.
>
> USER/CRUD is simple by definition.
Whose definition? I have no idea what you are talking about.
CRUD stands for Create, Read, Update, Delete, and is meant
to describe typical data access and entry UI's. Some are
simple and some are complex. (Sometimes the customer wants
silly things that overcomplicate them IMO, but they pay
my bills. I may raise concerns in a polite way, but they call
the final shots.)
> Whichever acronym one uses the
> operations are trivial and very similar but they are performed on
> mountains of data. One is essentially just reformatting the data.
> However, that reformatting is usually highly constrained, which is why
> rear end query languages like SQL evolved; they captured the invariants
> of accessing data stored using the relational data model. That reduces
> the level of tedium in collecting data by raising the level of
> abstraction of access.
>
> >
> > But if you have a specific example where relational tends
> > to choke or be complicated compared to OO, I would like to
> > inspect it. I am sure there are a few such cases because
> > nothing is good at everything. However, for the vast
> > majority of business applications, procedural/relational
> > is superior IMO. At least not objectively worse.
>
> Where did I say that the relational model "chokes" for data storage? It
> is an excellent paradigm for that, which is why one doesn't see a lot of
> CODASYL anymore.
>
> However, client side applications (or at least a largish subset of them)
> aren't simply about USER/CRUD processing of large volumes for data.
> They do complex manipulations of the data and for that one needs better
> paradigms that are oriented around behavior as well as data. The
> relational model sees the world solely in terms of static data but
> problem solutions are inherently dynamic.
Example still desired. What is behavior and what is data is
largely interchangable. For example, early GUI API's tended
to look behavior-centric. Over time they started to be more
declarative (data) with some way to provide hooks to
execute events (onClick, onValidate, onDelete, etc.) Events tend to be
procedural in design and concept.
>
> >>>Context-specific is often not "long-term". Besides, one can
> >>>reformat stuff as needed in a given module without all the
> >>>syntactical overhead and "setup work" involved in OO.
> >>>For example, split it up and put it into an associative
> >>>array that a particular task needs.
> >>
> >>Actually being context-specific is crucial to large scale reuse.
> >>Focusing on abstracting the invariants of a specific subject matter and
> >>encapsulating them properly behind interfaces is an excellent way to
> >>provide long-term stability and isolate changes.
> >
> >
> > That is what a schema is: an interface. Data-centric interfaces
> > are just as useful as behavior-centric interfaces. Plus, they
> > make inter-language communication easier than behavior-bound
> > approaches.
>
> However, you said it yourself: it is a data centric interface. That's
> fine for data storage but it doesn't cut it for <nontrivial> data
> processing.
Nobody says that relational does the entire thing. That is why we have
things like functions and loops.
>
> BTW, I disagree that interface is a good analogue for schema. A schema
> defines a model of data entities. It defines what those entities are.
> An interface defines access to entities. So SQL is an interface for
> accessing data defined by a schema.
I disagree that "interface" must be bahavioral.
> >
> >>Maintaining a narrow
> >>focus facilitates recognizing invariants. That's why we have GUI
> >>builders, web builders, and RAD IDEs; they each abstract invariants of a
> >>very narrowly defined subject matter. In fact, note that SQL is an
> >>example of abstracting the invariants of accessing RDB persistence.
> >
> >
> > There you go again: "persistence".
> >
> > But you are heading in the right direction in that databases came from
> > the packaging of *commonalities* of data-handling into a
> > language-neutral standard (more or less), IOW "abstraction". OO apps
> > tend to want to reinvent all that from scratch for each and every app.
>
> I already pointed out in this thread somewhere that the RDB view and the
> OO view are peer views of the same underlying problem space. They are
> mappable to one another but they are not derived from one another.
> Similarly, functional programming, expert systems, and other software
> solution paradigms also present peer views of the same problem spaces.
> One picks the right view to solve the problem in hand.
Okay, but I don't see much use for OO for the vast majority
of applications I work on. However, there is still a bunch
of hype around that it is the best and only tool for
all application development. I am still curious
to see a typical business need that fails for procedural +
relational, or at least grows messier than an OO equiv.
I don't question that there may be a few, but not much
more.
>
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
-T-
- Next message: _ee_: "Rock Paper Scissors - dual dispatch"
- Previous message: Arkadiy Vertleyb: "Re: Too many features"
- In reply to: H. S. Lahman: "Re: Relational model versus object model"
- Next in thread: Alfredo Novoa: "Re: Relational model versus object model"
- Reply: Alfredo Novoa: "Re: Relational model versus object model"
- Reply: H. S. Lahman: "Re: Relational model versus object model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
