Re: OOP - a question about database access

After takin a swig o' Arrakan spice grog, Costin Cozianu <c_cozianu_at_hotmail.com> belched out...:
>>>
>>> If recognized OO writers show this "understanding" of the data
>>> management issues, imagine the rest.
>> The above comments from Bob do not have any relation to "data
>> management issues". Why would a database be a good place to validate
>> text from an input field, wouldn't it make everyone's life a lot
>> easier if data were validated before making a write to a DB?
>
> Well, just because you typically *have to* do it in three places
>
> 1. First in the client (JavaScript)
> 2. Second in the middle tier (ASP.NET, Java, etc. )
> 3. Have it as a constraint defined in the database.
>
> Any solution less than all three is pretty much guaranteed to be a bad
> solution

It's fair enough to say that you'd like for the enforcement to take place at all of those levels.

I agree that it improves things to have a constraint applied in multiple places, as opposed to _solely_ in the DBMS.

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.

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.

It would be pretty slick to pass upstream some set of functions with a Lisp-like "OK-P" convention;

   COUNTRY-OK-P, LOCALITY-OK-P, and such.

The notion of having COUNTRY-OK-P is a very useful example of the challenges in this...

It ought to be easy enough to pass upstream some set of "domain constraints," such as:

  DATESTAMP-P - Which validates that a given field is actually a

                legitimate date stamp

  ID-LIKE-FORMAT-P - which validates that the customer ID conforms
                to some particular alphanumeric format, perhaps with a
                particular length, perhaps involving matching it
                against a regular expression.

  DATE-STAMP-RANGE-P - which validates that a particular field is a
                date stamp, and falls within a particular (static)
                range.

It's pretty easy when it's a matter of validating the format against a static rule, or against a static value.

It is a little less straightforward to "pass upstream" the notion of validating domains against one another. For instance, that START_DATE must be less than or equal to END_DATE.

The case of COUNTRY-P is one where it is attractive to cache the likely-few-hundred countries in the world on the client, and check data entered against them. Regrettably, that offers two conspicuous problems:

1. Pushing the values to higher tiers in a "standard" manner;
2. Invalidating the cache when the list of countries changes. [For instance, "Macedonia" recently negotiated changes to the relevant ISO country codes.]

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

-- 
output = ("cbbrowne" "_at_" "cbbrowne.com")
http://cbbrowne.com/info/linuxdistributions.html
The *Worst* Things  to Say to a  Police Officer: Hey, is that  a 9 mm?
That's nothing compared to this .44 magnum.