Re: foundations of relational theory?

Disagree with it or not, I have found this basic model pretty compelling. I am sure most of us developers have create similiar structures within our own RAD environments (common read routines, etc).

My point was Pick fits into this model very well. Most of the complaints stated here was how pick does not enforce certain integretity (schema, variable types, many-one relations, etc) out of the box without coding. In SQL this is enforced by the SQL application. With a business logic layer, Pick I believe gets an advantage since in pick we wrote this integrity in code anyways. Pick then does not have to go thru another filter (the sql app) before touching the app.

As for SQL, my Father was a 10+ year Informix 4gl programmer. He even had the opportunity to complete the Informix School training. He spent his last few years as a consultant, doing work at places like Columbia Sportsware, Lockheed Skunk Works, etc. He is now working for me and has learned pick. Once he got used to the system he was very impressed with our OLTP speed. Our classic, select,loop,readnext record,update,repeat functions in his opinion are VERY fast. I have found this interesting since our hardware here is much smaller than the hardware he was dealing with at the informix shops.

He has felt that in most SQL shops much of the integrity bragged about here is actually hard to use and very often left to the app developer.  Triggers are required in most instances (outside schema validation) and he has found most shops do not use it. While it may be simple to create a trigger than enforces the one-Many relation (do not allow a delete of the master record if childs exists), it was nearly impossible to keep somebody from going in with SQL and wiping out child records. In pick the classic Invoice is a single record (i.e. a invoice Object) and therefore this type of integrity can actually be enforced with our Triggers.

This I feel is why the 3-tier model is superior. You do not allow individual table access, but only access to the overall data object. Integrity is enforced at the INVOICE level, not the lower table level.  In this area Pick's shortcomings I believe then become a strength. Since we are already used to writing our own Schema enforcement at the coding level and then are not forced to go thru another validation level (the sql engine) we get a bump in performance.

This is why I feel if we are talking Theory, I believe the 3-tier model is basically allowing us to create Custom SQL engines that wrap around Data Objects instead of the underlying Tables. If we want to talk theory, this is where we are going. Arguing about the lower Database Schema I believe is like returning back to Assembly level Coding Theory. We are way past that and most of us now code in Higher Languages and who cares about Stacks, Swaps, etc.

• Patrick

cmurthi <xyzcmurthi_at_quest.with.a.w.net> wrote in message news:<3FAA5EA2.5090407_at_quest.with.a.w.net>...
> byrmol wrote:
> [originally]
> > 1) It has a general theory that has gone unchallenged for hundreds of
> > years. (Set theory - Georg Cantor 1874, Predicate Logic from
> > Aristotle 322BC to Frege, Peno, Godel and Turing & Church (1936) who
> > prove that it is not "decidable").
> and I replied:
> >I assume (and I can stand corrected) that this is set theory,
> > and while relational theory springs from it, it's a stretch to imply
> >that relational db theory was somehow even postulated in 1874 or
> >before. But as I say, the theory may be provena[n]ced there.
> and brymol replied:
> >Where did I imply it?
>
> Please read original quote. you reference "set theory?" there clearly.
> And the implication is that relational db theory links to that, and has
> been unchallenged etc.
>
> somebody wrote:
> >> This model has the advantages of Forced Data Integrity, the
> >> end user does not have to know our data model. Essentially it creates
> >> customized mini-sql engines for our data objects. As I study this
> >> model more and play with it with Microsoft .net, Disconnected
> >> datasets, and XML data sets, I really feel this is the future.
>
> > This quote gave me a good chuckle, because I am currently on a project
> > that does this. Nearly the entire enterprise's schemas are replicated
> > outside the DBMS's into these XML schema (XSD) for validation before it
> > hits the data tier.
> >
> > Guess what happens... Any DB change HAS to be reflected in the middle
> > tier. The middle tier has become a memory hungry, CPU churning pig with
> > the added bonus of wiping out all logical/physical separation advantages
> > that the DBMS had and for good measure coupling the data tier with the
> > middle tier....
> >
> > "Welcome to the dumb future"
>
> no, "welcome to the real world," is more like it. 3-tier models (even if
> I also disagree with the philosophy,) will continue to gain acceptance,
> and the double validations will be a fact of life. The piggishness of
> the middle tier is just an example of bad implementation and has no
> relevance.
>
> Come to think of it, if you believe that the middle and upper tier
> programmers can do a good job, you could remove all data integrity
> constraints from the db, and let it do what it does best-data storage,
> retrieval and (physical) data integrity (duck.)
>
> Chandru Murthi
Received on Fri Nov 07 2003 - 18:18:05 CET