Re: Multiple specification of constraints

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:<D3n1c.20847$rG4.14508_at_newssvr31.news.prodigy.com>...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> news:c1ku71$jqu$1_at_news.netins.net...
> > "Marshall Spight" <mspight_at_dnai.com> wrote in message
> > news:9wd%b.121916$jk2.526707_at_attbi_s53...
> > > I think the optimal solution here is to have the constraints specified
> > > declaratively and centrally, but to be able to *additionally* execute
> > > them remotely, i.e., on the client. That last part, on the client, is
> actually
> > > the least essential place for validation to occur; it's the only one
> that
> > > can be omitted. It's always essential to have it enforced centrally, on
> the
> > > server, because clients are typically not running on trusted computing
> > > bases.
> > >
> > I agree they should be specified "centrally" but don't necessarily agree
> > with what you mean by that. If you mean that they should be specified in
> a
> > way that is tightly coupled with database storage services, I disagree.
>
> Why is the storage even an issue? Surely we've abstracted above storage by
> now? A relational DBMS says what your data means - would you say that the
> Pick dictionary is "data storage"? The dicionary seems to be the "meaning"
> of your data, at least in a limited way. With relational languages like D4,
> you can say much, much more.
>
> If people just think of a database as a way to write to disk, then I guess
> the conversation is fairly stymied already. Hmph.

Well, when they refer to the DBMS as "CRUD services", I think we can see what kind of goggles they are wearing! Received on Wed Mar 03 2004 - 22:39:56 CET