Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c1lk7d$aj4$1_at_news.netins.net...
> If I understand you correctly, you are actually IN FAVOR OF DUPLICATING
THIS
> COMPLEX DATA -- locating it once in the database and again in a different
> language in the business rules used by the GUI. Is that correct?

Yes, it's a necessity if you want any assurances. If you only have ONE application, with ONE GUI, then you may not have a problem (for now).

And the rules aren't duplicates - not exactly. For example, the GUI sort of needs the DBMS to provide rapidly-changing data like currency exchange rates, right?

The GUI, like an XML doc or a nested data structure, is a single and simplistic view of things. Real things can support multiple views, from various angles, which each have utility for different parts of the business. But even in apps I've written, I've provided GUIs that let them envision the data in different ways (sometimes they wanted to see paint color variants by model, sometimes they wanted to see models by color variant.) Letting one particular GUI govern my rules is putting the cart before the horse.

> It does
> seem like you are in the majority, but I just don't see what is gained by
> coding these rules twice in different languages -- sounds like busy work
> that leads to complex-to-maintain software and is likely to be out of
synch
> with itself, with app programmers prone to change only the application
> software and not the dbms constraints when they can do so.

I agree, code them in an RDBMS and then apply simple templates to generate the UIs. We're in agreement.

> "Centralized" is fine, but another minor point today (more major perhaps
in
> the future) is that the database could be one of many accessed by the
> software application, so that a central place for the business logic /
> constraints / data validation information would more likely be within the
> software code that is external to one of the databases, right?

If the application accesses many DBMSs, then the other programs that also access those DBMSs have rules of their own. You have a serious rule coordination problem.

If your app is going to be the only one setting the rules, then why have multiple DBMSs anyway?

If the databases really are separate, then you need conversion logic (predicates) which allow interpretation in one or both directions.

• Eric