Re: Transaction Oriented Architecture (TOA)


H. S. Lahman wrote:
Responding to Jacobs...

Normally I don't feed the trolls, but this post had me LOL. You've
really outdone yourself this time.

The basic problem is that the RDB paradigm is designed for generic, ad
hoc access of data.


Bullhonk!

I used to use custom, local, and/or temporary tables all the time to
solve app-specific problems, but it unfortunately fell out of style for
tool vendors when everybody thought OOP would replace such techniques.
The "Big-Iron" view of relational is an Oracle invention more or less.
In desk-top-based app software kits such as FoxPro and Paradox,
querying from the server and chomping tables for local needs was common
and easy. And you get query ability out-of-the-box instead of
roll-your-own set/get/find/look-up methods that OO always reinvents
bloatingly and inconsistently.

Let me see if I understand this. You need a temporary table to solve
some problem _in your application_.

Need? No. They are just often simpler than arrays and OOP pointer pasta
(if the language or libraries support them).

So you add the table and fields to
the RDB schema, populate it with tuples, access it with queries, and
then delete it when the application is done.

More or less. Note FoxPro and other dBASE-derived kits optionally
allowed a table to be a single file without any forced attachment to a
"schema". Some dialects even deleted the files for you when the app was
finished by declaring it temporary. This is different than the "big
iron" view of schemas.


You do this where every
operation involves milliseconds for physical read/write operations (not
to mention the DBMS overhead of modifying the schema and contention for
DB resources in a multi-user environment). And somehow you feel this is
a better solution than providing a table in memory where operations are
measured in microseconds or nanoseconds and you don't load the server
unnecessarily?

The tools I used cached to RAM if available. This is good because if
they grow large they automatically use disk as needed. I didn't have to
worry about a RAM/disk dichotomy. I even tested it multiple times and
saw how it used RAM caching until RAM was full, and then it used disk
without the programmer having to flip any switch. It abstracted away
the RAM/disk boundary.

And performance was satisfactory even on a 286, long before Pentiums.

Your perception of tables and relational is too heavily shaped by "big
iron" RDBMS brands. You OO'ers need to get out more.

And what is this about a "multi-user environment"? In the desktop days
they were kept in the temp folder. As far as something like a web app,
one can still use tables with userID as part of a compound key to
emulate temp tables. It would be nice if vendors offered better temp
table features, but if they don't it is not a show-stopper in most
cases. There is a distinction between bad vendors/products and bad
paradigms.



IOW, it is optimized to be independent of what
problem is being solved with the data. Once one is outside the
CRUD/USER arena, applications are optimized to solve very specific
problems. That optimization involves different approaches to things
like relationship navigation (e.g., object-level instantiation vs.
table-level). So the views of the data should be /expected/ to be
different. Therefore one solves the business problem first and then
worries about how one maps that solution view into the DB view.


Example? There is no objective evidence that OOP better fits the
"problem space" than tables.

Yet another of your stock-in-trade forensic ploys: you are being
deliberately obtuse.

It was your claim. If you didn't mean it "better fits problem space",
then the obtusness is perhaps on your end.


I know you know better because I've already pointed you at the most
comprehensive book on OO Class Modeling available, Leon Starr's
"Executable UML: How to Build Class Models", and pointed out that Leon
uses tables as an analogy for almost all of his examples. I've also
pointed out repeatedly that Class Models are normalized using the same
basic RDM rules as RDB schemas. IOW, tables per se have nothing to do
with the points I was making. In fact, in the quoted paragraph I
explicitly identified the main paradigm difference (i.e., the way
relationships are instantiated and navigated) -- which you chose to
ignore as yet another forensic ploy to pull the opponent's chain.

I don't know what you are refering too here. How about some scenarios
or code that show OOP being better than relational.


In addition, a big advantage of encapsulating in a subsystem is large
scale reuse.


Reuse is an out-of-date OOP claim. Many OO'ers don't even bother
defending reuse anymore.

Otherwise show me something that OOP makes reusable that
procedural/relational can't. I will not take your word for it.

The post was largely about such an example: reusing a subsystem across

It is also about whether tables are/can be app-specific.

applications for accessing /any/ RDB in /any/ problem context. You just
chose to ignore that.

I have yet to see a *good* API that does this. There are too many
vendor-specific implementations and vendor-specific nice features that
save a lot of SQL if they exist. It is less trouble to talk to the DB
directly in most cases and give up trying to wrap everything you hate
or don't understand behind verbose classes.

Even if OO was by chance better for building DB wrappers, that does not
necessarily imply that it is better at building custom biz apps. The
more something resembles a device-driver, the better OOP will be at it.
Unfortunately, the device-driver view does not scale to every domain.



In addition, you pull out yet another tired forensic ploy and try to put
words in my mouth to the effect that one cannot have reuse with P/R.
Where did anyone say that one could not encapsulate subsystems behind
APIs and reuse them using P/R? Modularity has been around every since
installable device drivers in Multics in the '60s. The OO paradigm just
does a better job of emphasizing and formalizing notions like
implementation hiding.

Prove it with code instead of brochure-talk.


Once one abstracts the invariants of the DB paradigm de
jour properly, then the subsystem can be reused across applications.
Thus the RDB paradigm is abstracted exactly the same way regardless of
the semantics of the data.


The "base" tables might be, but custom/local/temp tables were very
common and easy in pre-OO-fad tools, as described above.

You are being deliberately obtuse again and focusing on your own
mantras. How does the RDB tell the difference between a temporary table
for a specific application and an enterprise table? It can't; it is
just a table.

You were suggesting that tables cannot be app-specific. I am simply
demolishing that myth. App-specific temporary tables are a powerful
and useful modeling tool. And easy to sift and debug than
pointer-centric pasta OO classes.


So even if one were silly enough to store temporary tables unique to the
solution in the RDB rather than memory,

The disk/RAM dichotomy is an artificial seperation that table systems
don't necessarily have to care about.

one would still access them
through the DB access subsystem with exactly the same identity mapping
as any other table. So the DB access subsystem's <invariant>
abstractions are exactly the same.

Give it up, [you]. You've been using these same forensic ploys for so
long they are transparent to the point of being comical. We all realize
now you are trolling here just to amuse yourself by pulling OO people's
chains. So now we are the ones laughing. Ta-ta.

Youz is Projecting. Your characterization of tables is simply WRONG.
They can be app-specific and they are not inharently slow nor
cumbersome. Accept your wrongitude like a man instead of a weasOOL.

H. S. Lahman

-T-

.

Relevant Pages

  • Re: Transaction Oriented Architecture (TOA)
    ... tool vendors when everybody thought OOP would replace such techniques. ... So you add the table and fields to the RDB schema, populate it with tuples, access it with queries, and then delete it when the application is done. ... Reuse is an out-of-date OOP claim. ... So even if one were silly enough to store temporary tables unique to the solution in the RDB rather than memory, one would still access them through the DB access subsystem with exactly the same identity mapping as any other table. ...
    (comp.object)
  • Re: To all OOP eggheads out there. I need A bit of design help
    ... Like any database driven program you should start by defining your ... if you plan to program oop. ... schema if you are into oop. ... business layer is business layer. ...
    (comp.lang.php)
  • Re: Multiple inheritance revisited
    ... For example if OOP is just a wrapper of a relational ... relational database, rather than in the code, you don't need so much ... OOP faciliates reuse, but sometimes you don't need so much ... Type) wrapper to relational models and business processes would be ...
    (comp.object)
  • Re: OO Books for newbies?
    ... management via all the cute shape, animal, and device-driver examples ... that OOP improves reuse, simplifies code maintenance, etc. ...
    (comp.object)
  • Re: OO Books for newbies?
    ... management via all the cute shape, animal, and device-driver examples ... that OOP improves reuse, simplifies code maintenance, etc. ... if you think OOP generates heated debates.... ...
    (comp.object)