Re: OOP - a question about database access
Date: Sat, 8 Nov 2003 11:05:41 -0500
Message-ID: <Xb-dnYUL___riTCiRVn-uw_at_golden.net>
"Christopher Browne" <cbbrowne_at_acm.org> wrote in message
news:boj3pf$1echi8$2_at_ID-125932.news.uni-berlin.de...
> The world rejoiced as "Bob Badour" <bbadour_at_golden.net> wrote:
> > "Christopher Browne" <cbbrowne_at_acm.org> wrote in message
> > news:bogm5j$1ef99t$2_at_ID-125932.news.uni-berlin.de...
> >> I agree that it improves things to have a constraint applied in
> >> multiple places, as opposed to _solely_ in the DBMS.
> >
> > Does it? Why?
>
> Because in a heavy-duty distributed system, a lot of work takes place
> before data ever touches the database.
Why is that?
> Supposing it's a "web application," it is good to constrain what is
> entered into web FORMs so that the DBMS doesn't have to roll back a
> lot of transactions because the user entered crap.
Why would an update involve multiple transactions?
> So, for instance,
> it's probably a good thing for "upper tiers" to validate that dates
> are actually dates, countries are actually legitimate countries, and
> such, so that by the time the data gets shoved at the DBMS, there is
> _some_ likelihood that the data is at least quasi-legitimate.
Why is the dbms not physically an "upper tier"?
> >> After all, it's going to be really irritating to fill in a web page
> >> with a bunch of data, and only discover that the values are
> >> Seriously Messed Up when you try to COMMIT the transaction to the
> >> database and discover it doesn't work out.
> >
> > It's also irritating when an error message prevents one from moving
> > focus to fill in a field that would make the current field valid. I
> > suggest it is even more irritating to discover that all of one's
> > data is messed up because someone installed an old version of an
> > application.
>
> Oddly enough, I haven't seen this being a problem, given some
> forethought.
Oddly enough, I haven't seen the problem you identified being a problem, given some forethought.
> - With SAP R/3, the "GUI component" will refuse to connect to servers
> that are too new.
That's nice. SAP R/3 also refuses to let the dbms manage data, which seems a little perverse. Do you not agree?
> - If I mistakenly try to start up a PostgreSQL instance with software
> of the wrong version for the data, it'll abort immediately.
How does PostgreSQL know the version of your application? Or which versions of your application are valid for its logical schema?
> - <sarcasm> Many applications "run best" with Internet Exploder
> Version Something-or-Other, and may refuse to run otherwise </sarcasm>
>
> >> The Right Way involves having some way of querying the database
> >> about "Constraint Metadata", and then having some sort of code
> >> generator that can transform that into Java/JavaScript/Perl/Python
> >> as needed to support the upper layers of the system.
> >
> > Why do you assume this "code generator" is external to the dbms?
>
> The code is external, and it would seem surprising for the code
> generator to be part of the very same program.
Why do you assume the code is external?
> >> I think it's a real attractive idea to automate creating validation
> >> rules that can be pushed upstream, but that doesn't make it easy...
>
> > I suggest it is no harder for the dbms to enforce constraints on one
> > computer than on another.
>
> Foreign key constraints are an exception as they require going back to
> the central authority.
Do they? Always? Received on Sat Nov 08 2003 - 17:05:41 CET
