Re: No knowledge of the database?
From: Alfredo Novoa (alfredo_at_ncs.es)
Date: 01/06/04
- Next message: Shayne Wissler: "Re: No knowledge of the database?"
- Previous message: Ilja Preuss: "Re: Test-Driven Design or Test-Driven Development?"
- In reply to: Bruno Desthuilliers: "Re: No knowledge of the database?"
- Next in thread: Bruno Desthuilliers: "Re: No knowledge of the database?"
- Reply: Bruno Desthuilliers: "Re: No knowledge of the database?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 6 Jan 2004 12:21:30 -0800
Bruno Desthuilliers <bdesth.tagada@tsoin-tsoin.free.fr> wrote in message news:<3ff970f1$0$28689$626a54ce@news.free.fr>...
> >>Believe it or not, I do know what's a DBMS and what it's good for !-)
> >
> >
> > Then you hide that very well.
>
> Ho, really ?-)
Yes, because you write many nonsenses.
> > No, you said business layer,
>
> Which *is* - from an application developper (OO or not, I'm not an OO
> bigot) POW - the application logic.
No, the business layer is the system logic, and it is always different
to the application logic except in the case of the stone age
monolithic systems, and the new OO aberrations.
> >so you are talking about to decoupling
> > the system's logic from the logical database design,
>
> Please re-read : "I'm talking about decoupling *application* logic from
> the logical data model".
The application logic should be the presentation logic. And to
decouple the presentation logic from the business logic is an absurd,
but if you mean that you want to decouple the presentation source code
from the business logic (the logical data model), the relational
approach is the best by far.
In many bad designed multitier systems, the middle tier IS a DBMS, but
a botched ad-hoc DBMS that expose pointers to users and manage the
data through procedural code transversing pointer labyrinths.
>
> > and both should
> > be the same thing.
>
> Ho, really ? So how does it comes that business rules tends to evolve
> way faster than db schemas ?
What a nonsense. Business rules design is database design. A database
design is a set of business rules.
There is no business rules you can not implement using a
computationally complete SQL DBMS. And for most business rules the
relational approach is orders of magnitude simpler.
> (tip 1 : usually because so many legacy applications directly depends on
> that schema that changing it is too costly. Now if only those
> applications had been written so that they were not so thightly coupled
> with the database logical model...)
You are talking about bad designed applications only.
> (tip 2 : could it be possible that some DBA, victim of the delusion that
> the DB is God and applications are only for data presentation, tends to
> be overconservative ?)
>
> > You confuse application and system all the time.
>
> I do not confuse anything. I'm an application developper, my job is to
> develop applications, that, just like the database, are *parts* of the
> whole system.
And the business logic is the logic of the whole system. You can
implement the same system's business logic in the application or in
the database and you will get the same functionality (ignoring
performance). The first approach was abandoned decades ago because it
was a disaster. Every professional should know that.
> > A logical database design is data + behavior,
>
> I still have to see an IS where the DBMS handle all the data processing
> and business logic !-)
Then you still have to see a well designed system.
>
> > but most OO coders don't
> > have a clue of what The Relational Model really is.
>
> Really ? Well, not being an OO bigot, I do use procedural and functional
> paradigms too
Most OO languages are procedural and a few functional. But I am saying
they don't have a grasp on modern data management theory, which could
be included in the "logical paradigm", nor procedural, nor functional.
>, so I can't tell. But if you took time to actually *read*
> (and understand...) what some OO coders here say about this, you may
> change your mind.
Most OO coders here say that RDBMSs are mere bit buckets and they can
be replaced by any other bit bucket.
>
> > RDBMSs are not dumb bit buckets.
>
> Certainly not. RDBMS are (more or less, according to the specific DBMS
> used) powerful data management systems. The fact is that if what each
> and every app needed was a 'dumb bit bucket', there would be no RDBMS at
> all.
Who needs the RDBMS is the system.
After decades of accumulated knowledge and failures, the best experts
realized that data management must be done by a set of specialized
applications called DBMS, and the applications should act as an
interface between the users and the DBMS.
> Another fact is that some (and not a few) applications don't have a need
> for a RDBMS. So please undertand that RDBMS *are not* the alpha and
> omega of information processing.
We are talking about business systems. But any information system
would benefit from a RDBMS. The Relational Model is simply the right
way to manage data.
> > RDBMSs are powerful logical deductive systems. The Relational Model is
> > nothing but the direct application of predicate logic and set theory
> > to the data management field (information processing if you prefer).
>
> The relational model (please drop the caps so it will look less
> religious...) is a theory. A pretty nice and useful theory IMHO, but
> still a theory.
For your info, I am completely anti religious. The Relational Model is
a proper name, and proper names are written with caps on the first
letter of each word.
And the pretty nice theory (model would be a better word), is simply
the best by far way to manage data. But many OO coders want to return
to the dark age when data was managed by the applications,
transversing pointer labyrinths using procedural code. Something that
was abandoned decades ago due its horrible practical results.
> <troll>
> Now you who claims to know everything about "The Relational Model" and
> RDBMS, please be kind enough to enlighten us, poor stupid and
> unlitterate application developpers, by telling us which RDBMS
> implements correctly the *whole* relational model.
> </troll>
<troll>
I never said stupid.
</troll>
There is not any perfect RDBMS, but it is not an excuse for a return
to the stone age. There are practical workarounds for many of SQL DBMS
flaws, and some flaws are not very important at practice.
What many OO coders and writers want to do is to return to the caverns
because the first buildings ever done have some cracks.
The problem is that the junk OO literature is overwhelming in quantity
compared to the few good books. It is called argumentum ad nauseam,
and it works very well.
> And also please tell us what to do with those numerous applications -
> that you don't seem to be aware of - that don't have a need for a RDBMS !-)
If they are not part of information system there is nothing to do.
Regards
Alfredo
- Next message: Shayne Wissler: "Re: No knowledge of the database?"
- Previous message: Ilja Preuss: "Re: Test-Driven Design or Test-Driven Development?"
- In reply to: Bruno Desthuilliers: "Re: No knowledge of the database?"
- Next in thread: Bruno Desthuilliers: "Re: No knowledge of the database?"
- Reply: Bruno Desthuilliers: "Re: No knowledge of the database?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
