On Sun, Mar 01, 1998 at 03:01:12PM -0500, The Hermit Hacker wrote:
> > The datatype employed is defined by domain which also
> > restricts the values to "YES" or "NO" or "RETIRED" or "DISABLED" or
> > NULL.
>
> Oh, cool...so, essentially, you are creating an enumerated(?) type
> to be used in a table?
Cool indeed! Actually, a domain definition can be useful for more
than just that: if you define a domain, and then use that domain as a
data type for various columns in various tables, you can change your
schema all at once by changing the definition of the domain. Also, a
domain can carry extra meaning. Look at this schema (using a somewhat
arcane syntax) for keeping track of suppliers, parts and shipments of
quantities of parts from suppliers:
DOMAIN S# CHARACTER (5) PRIMARY
DOMAIN SNAME CHARACTER (40)
DOMAIN P# CHARACTER (5) PRIMARY
DOMAIN PNAME CHARACTER (20)
RELATION S (S#, SNAME)
PRIMARY KEY (S#)
RELATION P (P#, PNAME)
PRIMARY KEY (P#)
RELATION SP (S#, P#, QTY NUMERIC (4))
PRIMARY KEY (S#,P#)
This is simplified from an example in "An Introduction to Database
Systems", by C.J. Date, taken from the 1981 third edition. Note how
the named domains become the default types for columns of the same
name as the domains, while the QTY column in the SP relation has an
explicit data type. Note also the constraints: the "PRIMARY KEY"
statements in the RELATION definitions make uniqueness constraints,
and the word "PRIMARY" in the DOMAIN definitions for S# and P# specify
that these domains are foreign keys, thus demanding referential
integrity from the SP table to the S and P tables. Neat, innit? :-)
Does modern SQL have this stuff? I'm not up-to-date, I'm afraid...
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
