Re: Multiple specification of constraints

"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...
> >
> > > I would advocate for use of a design that might include an http server
> > > with a jvm as the location for all central rules/constraints processing.
> >
> > This is exactly the architecture that I've worked on every day for the
> last
> > two years and it doesn't work very well. For one thing, it introduces a
> > requirement that all code that will write to the database has to go
> through
> > the jvm. What do you do about your C++ code? What do you do about
> > your code that cannot withstand the occasional garbage collection pause?
> > What do you do about third party software you want to integrate that
> > is written to use an industry standard interface such as jdbc or odbc?
> > It also means that your constraints have to be written manually into
> > procedural code instead of specified declaratively, and that means
> > bugs, and *that* means corruption and constant maintenance.
>
> These are good points, Marshall. The questions about the difference in
> language -- whether your C++ code needs to execute DBMS statements that
> employ the DBMS language specs or have to interface with your Java code in
> order to get to the database is a matter of getting implementations to the
> point where this is not an issue. There is no conceptual or theory issue
> here, but I appreciate the practical issue that needs to be addressed.

Agree on all counts.

> 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.

> While there is some similarlity with the various
> flavors of SQL, when we talk about the language used to code constraints in
> Oracle and those for SQL Server or DB2, we are not really talking about the
> same language.

I can't comment on this.

> > 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.

> > > 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 agree that user interface is important.
> >
> > > I forget who wrote up the story of a major retail chain that built a new
> > > store in a certain zip code because their data said a lot of people go
> from
> > > that zip to another to go to this chain. They had to close the store
> for
> > > lack of customers. It turnes out that one of the retail clerks didn't
> like
> > > the constant question of what zip code the buyer was in, so she always
> > > entered her own to get past that question. Software usability is key to
> > > clean data. The GUI having full knowledge of the business rules
> > > (validations & all constraints) is critical to a usable GUI.
> >
> > I agree that good UI is important. You example, however, illustrates
> > an error in application design, not with integrity enforcement.
>
> Yes, my point was that constraint checking is only part of the picture.

Fair enough.

> > Worst case, it's possible to defer checking input until a round trip
> > to the server is done; this is still secure and can be made into a decent
> > UI, although it's clearly not idea. The alternative is to have insecure
> code.
> >
> I'm missing the point of where the insecure code is?

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.

Consider the least important client-server code there is: multi-player games. Generally, for performance reasons, significant validation takes place on the client, and these clients are being hacked to death. The term "aimbot" was coined to refer to a custom multiplayer game client that automatically fires the weapon so that it will hit the target. (I can remember this idea being discussed in the early 1980s.)

Given that winning points in a game is enough motivation for hordes of hackers, consider how important server-side validation is for an online store, to say nothing of a bank.

> >
> > I think the idea of having it be possible to automatically replicate the
> > integrity checks on the client (or on whatever earlier tier) is the better
> > approach to pursue.
>
> Have you seen anyone try to do this? Do they end up with OS-independent
> applicaxtions? DB-independent? How do they do that? I'm not grasping the
> solution to this that includes only one set of validation specifications and
> hosts those in a proprietary database engine with a proprietary SQL
> implementation. It seems that any such solution would make the application
> tightly coupled with the database implementation, right?

The only system I've ever seen have any real success with platform independent applications is Java. I do not consider C-style portability (i.e., spend a day editing header files before you can compile) to be platform independence. I suppose .Net has a shot at this same kind of independence; we'll see how Mono goes.

But I'm not sure that DB-independence is a real thing today. By way of comparison, does OS independence exist? I would say not.

> Thanks for pursuing -- this is a difficult one for me to get my arms around.
> Is there any vendor out there that does this well? --dawn

No, for most of these issues I haven't even seen it being attempted.

Marshall Received on Fri Feb 27 2004 - 10:08:49 CET