Re: Relational model versus object model
From: Topmind (topmind_at_technologist.com)
Date: 02/25/04
- Next message: floppy: "Re: Design Pattern Newbie Question:about creating object"
- Previous message: yaoyang: "Design Pattern Newbie Question:about creating object"
- In reply to: H. S. Lahman: "Re: Relational model versus object model"
- Next in thread: Alfredo Novoa: "Re: Relational model versus object model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 24 Feb 2004 22:31:13 -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?
>
> Not if the IC application takes care of the inventory management problem
> while the DBMSes take care of the data management problem.
They work together. Relational is a high-level set of building
blocks.
>
> >
> > 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.
>
> You are pulling one of your familiar forensic ploys. You asked for an
> example and now you are critiquing the example itself rather than the
> point it makes.
Let's back up a bit here. You stated, "Each reading initiates a thread."
Is this a business requirement, or your particular implementation
suggestion? If the first, then why is it a hard requirement?
> >
> >
> >>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.
>
> Schema designs are a static description of data. I'm talking about the
> unique data views, relationships, and behaviors associated with solving
> specific problems. Those don't belong in a DB, especially an enterprise
> DB. They belong is applications dedicated to solving the specific problems.
Well, select something specific and lets throw some psuedocode at
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.)
>
> And USER is an acronym for Update, Sort, Extract, Report. Either way,
> that is about as simple as data processing can get. As you point out,
> they describe "typical data access and entry UIs" (i.e., UI/DB pipeline
> applications where the processing in between is minimal). As soon as
> one puts something more complicated between the UI abd the DB that does
> more complex things than these sorts of operations, one is no longer
> doing pure CRUD/USER processing.
"CRUD/USER" is a very GENERAL way to describe typical interface
behavior from a high-level. It is *not* a specific algorithm.
Of course there is going to be a lot of back-room stuff
and batch jobs running, etc.
Almost every biz app has "entities", and in many cases users
manage the contents of these entities. The tradition is
CRUD/USER-like conventions. They will be in almost any
business system one way or another because humans
manage content.
>
> >>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.
>
> Your doing your give-me-an-example ploy again.
Why is asking for an example considered an evil ploy?
Mantra and words only go so far so at some point
we need to inspect something more detailed. I don't get you.
It is kind of weird debating someone who seems to
view me as somebody always trying to pull shananagins.
However, I am getting used to it. Many OO fans think
I am pure evil. It goes with the territory of attacking
sacred cows.
> I just gave you one in
> the IC system. Have you ever seen the sorts of forecasting necessary
> for IC? Or the complexity of the stocking triggers? Or scheduling
> delivery truck routes from warehouse to stores? Or dealing with things
> like electing to pay railroad car demurrage to store goods when the
> warehouse is full?
I have not dealt with a "huge" system resembling such, but I have
dealt with a medium-sized one. It had about 15 or so simultaneous
users (logged on). If you are going to depend on argument-by-resume
("trust me because my project is bigger than yours") to justify
your position, then lets end this here and now.
> In that processing context the UI and the DB are
> just low level perpiheral services.
"Low-level" is not very precise. OO classes are also
"low level" things. We use lots of low-level things
to build high-level things.
And, I don't consider databases "low-level", but
rather medium-level. Low-level is things like
dealing directly with disk and RAM addresses.
>
> >>>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.
>
> Tell that to Novoa; he thinks /everything/ is in the DBMS, including
> stuff like forecasting and truck routing algorithms for IC.
One can certainly do such. Many database language dielects are indeed
Turing Complete. Whether that is the best way or not is
another matter.
>
> Your VB functions and loops are in support of CRUD/USER processing in
> DB/UI pipeline applications. Try doing an MLOC application in VB and
> then try to maintain it. When one gets out of CRUD/USER one needs more
> than just functions and loops to solve the problems.
Most of the larger shops I worked at never had "One Big EXE". They generally
split large applications into many smaller applications. DIVIDE AND
CONQUER, remember? The size of each "application" is more or less
the same regardless of the company size. (Sometimes I feel that
"application" is an old term left over from the fat-client days.
If there is a division that matches "application", it tends to
be per deparment. But department size is generally indepedent of
company size. Large companies simply have more departments.)
Each such application is linked to others mostly
via the database(s). The database is like a large river with
small villages living on the edge of the river and doing commerce
via the river boats.
Almost every larger shop I have seen has all
kinds of different applications feeding
off of the database(s) to share info and cordinate with each
other. For example, one place had several MS-Access applications,
some VB apps, some PB, some web apps, and database batch jobs, all using
the same data. (Sometimes MS-Access gobbles up database resources
though if the developer is not careful. But, I am not
promoting MS-Access. Part of the problem is when it
does non-relational things.)
I have yet to see this model fail (except when really stupid
developers F things up). When people brag about
"millions of lines of code" for a single "application", it makes
me wonder what the hell they are doing. It probably should be split up
into smaller chunks.
>
> H. S. Lahman
-T-
- Next message: floppy: "Re: Design Pattern Newbie Question:about creating object"
- Previous message: yaoyang: "Design Pattern Newbie Question:about creating object"
- In reply to: H. S. Lahman: "Re: Relational model versus object model"
- Next in thread: Alfredo Novoa: "Re: Relational model versus object model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
