Re: Multiple specification of constraints

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:BOD%b.67294$Xp.319435_at_attbi_s54...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c1mimq$40n$1_at_news.netins.net...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:J5z%b.420838$na.810280_at_attbi_s04...
<snip>
> > The
> > question of whether OO code (those OO types don't like to be called
> > "procedural") or declarative code or whatever language is employed to
"spec"
> > the constraints is somewhat a matter of taste and efficiency. I prefer
> > removal of all declarative code because it is data specified to a
specific
> > database implementation.
>
> That seems strange to me. Using nondeclarative code strikes me as decidely
> inferior, because one needs to write code to enforce each constraint in
> every location where it is applicable, whereas with a declarative
approach,
> one merely has to say what the constraints are, and the enforcement is
> automatic.

In either case, the "coder" plays a game with the compiler/interpreter trying to write code that is then handled properly. I've used many languages and don't have a big OO vs procedural vs declarative vs functional leaning -- you;ve got your functions, your variables, and your values and then you take input and make it output, whether you code only "specs" or only "procedures". There is some benefit with reuse in the database engine as well as hiding implementation details from developers. But there are other ways to accomplish that without tying your company's business rules to a single database vendor.

<snip>
> > Something that allows the validation logic to be executed remotely
> > > is clearly very useful.
> >
> > This is only feasible if the validation logic (combination of the specs
&
> > the DBMS's use of the specs) is not tightly coupled with the storage &
> > retrieval functions of the DBMS. I haven't seen RDBMS's that attempt
> > anything like this, have you?
>
> No, I haven't. And, in fact, there are certain constraints that can't be
> fully remoted, like enforcing uniqueness. But I still think it's a useful
> area to think about.

Yes, there are some constraints that would not be handled in the GUI and others that would not be handled in the database (such as constraints local to that particular application, but not global to the database). So, perhaps instead of suggesting that all constraints be moved forward in the process, there be some that are only in the db and others only in the business logic tier, but I really object to doubling up from both an integrity and an agility perspective. Because we MUST have the information accessible to the GUI to do type checking on data entry, at the very least the type checking specifications, logic, and run-time environment should be available to the GUI, whether provided in part by a database vendor or not.

> > > > Additionally, I would argue that the user interface is the MOST
> > important
> > > > place for knowing the constraints so that the user interface can be
as
> > > > intuitive as possible, preferably written so as not to permit any
> > illegal
> > > > data from even being entered (but where that isn't feasible, at
least
> > > > letting giving the user the opportunity to fix it immediately). The
> > user
> > > > interface makes a big difference in the accuracy of the information
> > > > collected.
> > >
> > > I disagree. This is a performance issue merely. If you have
> > > validation code only on the client, then other people will write
> > > code that skips the validation step and enters whatever data they
> > > want. People hack e-commerce sites in this way all the time.
> >
> > That's not what I intended to say -- my point was that the UI needs to
have
> > knowledge of validation information, such as T/F, radio button or check
box
> > data, etc It is critical that this be there -- the user needs the best,
> > most-likely-to-produce-accurate-data-entry information it can get. I
don't
> > really have to argue for that since it isn't until some of the pathetic
> > web-page forms that developers started considering not editing entries
until
> > late in the process. So I think that most people (including you) would
> > agree that the UI needs this info. You point, I think, is that the UI
could
> > get this info from the DBMS. However, then the UI needs the logic
engine
> > that the DBMS uses to process such specs.
>
> Yes, this is a requirement.
>
>
> > I am in complete agreement that
> > it should not be hosted by clients -- I agere it should be centralized.
I
> > just don't see the proprietary DBMS with its proprietary version of SQL
and
> > its proprietary engine for applying constraint logic and such moving out
to
> > the front of OS-independent and database independent applications and
> > addressing this.
>
> But now you are talking about marketing issues and not theory ones.
>
> The proprietary nature of most SQL implementations is an accident of
> the marketplace.

I would suggest that I'm talking about the usefulness of the model in its implementation. The only reason to apply a model is for its usefulness unless we are just playing mind games. I'll reiterate that any theory about serial killers that can't actually lead to capturing them is really uninteresting to me.

<snip>

> In the modern context, virtually all client code is insecure. Any code
> that doesn't execute in a locked closet accessible only to trusted
employees
> with separation of concerns is insecure. Here, separation of concerns
means
> the developers who write the code do not have the privileges to execute
> the code in the production environment.

I suspect that Jini 2.0 with JERI and the Service UI addresses your concerns here ( www.jini.org )

<snipping rest for time considerations>
--dawn Received on Sat Feb 28 2004 - 00:27:29 CET