Re: Lots of code. How many tables.

"ben brugman" <ben_at_niethier.nl> wrote in message news:402ce522$0$1408$4d4ebb8e_at_read.news.nl.uu.net...
> > > Only as a last resort when one has no other option. Otherwise, it only
> makes
> > > sense to manage data integrity with a data management system.
> >
> > Well put! Apart from being blinkered ("the only way data gets in is
> > via THIS application code"), enforcing data constraints in the
> > application is far more difficult than most people who try to do it
> > realise. For a start, EVERY bit of application code that inserts a
> > row into a table that has an application-enforced "foreign key" to a
> > generic code table (GCT) better LOCK the parent row in the GCT to
> > prevent another user deleting it...
>
> Going with the two of you, how to implement a constraints with
> subtypes. For example we have a supertype A which can have
> 5 subtypes B,C,D,E,F.

Are you referring to entity types or to data types? Regardless, I suggest you look into Fabian Pascal's _Practical Issues in Database Management_ book. http://www.dbdebunk.com/page/page/623335.htm In fact, Fabian's recommendations at http://www.dbdebunk.com/page/page/859889.htm are about as good a recommendation as you will ever get.

If you already work with an SQL dbms and you want to jump-start some particular issue, I might suggest you reverse the order of _Intro_ and _Practical Issues_ from Fabian's suggestion.

> There is a type X which has to be of subtype C or D.

A obviously has more than 5 proper subtypes, because X is also a subtype of A.

> And there is a type Y which can be of subtype C,D,E, (one, two or
> three at the same time).

And Y is also a subtype of A.

> As fare as I know the above can only be implemented in code.

Relational domains are data types. All one needs to implement the above are user-defined data types that support type inheritance. Date and Darwen spell out how to achieve this relationally in _The Third Manifesto_, which you will often see referenced as TTM in this group.

> (If you have another solution to this 'arc' problem which is simpler,
> please inform me).

See above.

> Or a more practical example.
> members can lend books, but only to an amount that can differentiate
> for each member. Most members can only lend 5 books, but some members
> can lend more, some less.

That's a rather simple constraint of the form: ( books_loaned <= lending_limit )

> I can build a model were this is checked by relational constraints.
> But I can also build this in the application, this last is simpler to
> implement and
> therefore cheaper.

How do you figure? It is a very simple expression that only needs to be implemented in on place in the dbms. If enforced in applications, one must make sure it is enforced in all applications including ad hoc applications. Obviously, it will be much more costly to implement in applications. Received on Fri Feb 13 2004 - 19:41:22 CET