Re: Dreaming About Redesigning SQL

From: Bob Badour <bbadour_at_golden.net>
Date: Sat, 25 Oct 2003 10:18:46 -0400
Message-ID: <DMSdnQAx4NQUGweiU-KYhA_at_golden.net>


"mikepreece" <member31023_at_dbforums.com> wrote in message news:3522109.1067057534_at_dbforums.com...
>
> Originally posted by andrewst
>
> > You could have:
>
> > 1) Uniqueness of key value (always)
>
> > 2) Domain constraints: e.g.
>
> > salary is a number between 1 and 99999 with up to 2 d.p.
>
> > status_code must be in list ('A','B','C')
>
> > 3) Row constraints e.g.
>
> > start_date <= end_date
>
> > if status = 'X' then end_date is not null
>
> > 4) Database constraints e.g.
>
> > start_date of assignment must be between start_date and end_date
> > of project
>
> >
>
> > In general, though, a table with no parent and no child is of little
> > use. It must contain information that has no relevance to any other
> > information in the database. Can you give an example or two of such
> > a table?

Dee, Dum, Integer. Is three enough or is it too many?

> > Integrity is not ALL about foreign keys. It means having sensible,
> > valid data in the table. Consider this row in an imaginary employee
> > table where no constraints are defined:
>
> >
>
> > Emp ID: 123
>
> > Name: (null)
>
> > Salary: -47,000,000,000
>
> > Date of Birth: 01-JAN-4783
>
> > Sex: J
>
> Date Hired: 01-JAN-1066 OK. Thanks. I'm learning a
> thing or two. I wasn't previously sure if the integrity constraints
> embedded in SQL tables were solely concerned with maintaining pointers
> for cascading deletes and whatnot.
>
> In my experience applications have layers - although some are extremely
> flaky while others are more sophisticated.
>
> I'm working on developing a 'development framework' to allow people
> (users) to develop applications to run on Pick-based systems. There are
> parameters and code modules that make up the rules to be applied in the
> different layers.

Here's a suggestion for Mike. Mike, learn the relational model. Build an application development environment where one can express logic in the higher-level logical constructs of the relational model, and that divides the task of integrity enforcement among the various components available to the low-level development environment.

[enumeration of internal layers snipped] Received on Sat Oct 25 2003 - 16:18:46 CEST

Original text of this message