New Type Definition Vs. Multiple Constraints

Question

I'm thinking of making a change to an existing database. We currently have check constraints on table columns enforcing business rules for those columns. (e.g. "ADDRESS1 has to contain a number".)
ADDRESS1 shows up all over the place in our tables. If we were to change this rule to "ADDRESS1 has to contain a number other than 0" I would have a lot of work to do changing each constraint and the chance of a typo is pretty great.
Would it be better to create a datatype that was the same length and had this restriction on it and then change the datatype of my ADDRESS1 columns to match? At that point I only have to make the change in one place anytime the business rule changes. If that is the way to go, does anyone have an example of creating a type that is a VARCHAR2 with restrictions? I'm having a hard time finding examples that aren't datatypes with multiple columns in them.
If I'm on the wrong track could someone please propose a better way to handle these types of things. Remember we are full of check constraints and most occur in multiple tables.
Thanks in advance,
Chris S.

Answer 1

Let's look at this from the other side of the street...
Using TYPEs to store data permanently is bad practice i.e. not relational. But as you appear to have a heavily denormalised database anyway you're no worse off by using them (but see below). ccording to the documentation Oracle does not support constraints on TYPEs. We can apply constraints on tables that use them but where's the fun in that? Let's have some user defined constructors....
SQL> CREATE OR REPLACE TYPE address AS OBJECT
  2  (  plot_no NUMBER(10),
  3     postcode VARCHAR2(10),
  4     street_1  VARCHAR2(30),
  5     street_2   VARCHAR2(30),
  6     county VARCHAR2(10),
  7      CONSTRUCTOR FUNCTION address(plot_no NUMBER, postcode VARCHAR2) RETURN SELF AS RESULT,
  8      CONSTRUCTOR FUNCTION address(plot_no NUMBER, postcode VARCHAR2,street_1 VARCHAR2,
  9                                   street_2 VARCHAR2, county VARCHAR2) RETURN SELF AS RESULT
10  ) NOT FINAL;
11  /
Type created.
SQL> CREATE OR REPLACE TYPE BODY address IS
  2      CONSTRUCTOR FUNCTION address(plot_no NUMBER, postcode VARCHAR2)
  3          RETURN SELF AS RESULT
  4      IS
  5        x_postcode exception;
  6        PRAGMA exception_init(x_postcode, -20001);
  7      BEGIN
  8         IF postcode IS NULL THEN
  9              RAISE x_postcode;
10         END IF;
11         SELF.plot_no := plot_no;
12         SELF.postcode := postcode;
13         SELF.street_1 := NULL;
14         SELF.street_2 := NULL;
15         SELF.county := NULL;
16         RETURN;
17      EXCEPTION
18         WHEN x_postcode THEN raise_application_error(-20001, 'Postcode cannot be null!');
19      END;
20      CONSTRUCTOR FUNCTION address(plot_no NUMBER, postcode VARCHAR2,street_1 VARCHAR2,
21                                   street_2 VARCHAR2, county VARCHAR2)
22          RETURN SELF AS RESULT
23      IS
24        x_postcode exception;
25        PRAGMA exception_init(x_postcode, -20001);
26      BEGIN
27         IF postcode IS NULL THEN
28              RAISE x_postcode;
29         END IF;
30         SELF.plot_no := plot_no;
31         SELF.postcode := postcode;
32         SELF.street_1 := street_1;
33         SELF.street_2 := street_2;
34         SELF.county := county;
35         RETURN;
36      EXCEPTION
37         WHEN x_postcode THEN raise_application_error(-20001, 'Postcode cannot be null!');
38      END;
39  END;
40  /
Type body created.
SQL> CREATE TABLE emp_addresses (id NUMBER, addr address)
  2  /
Table created.
SQL> INSERT INTO emp_addresses VALUES (1, address(123, 'SW12 900'))
  2  /
1 row created.
SQL> INSERT INTO emp_addresses VALUES (2, address(56, null))
  2  /
INSERT INTO emp_addresses VALUES (2, address(56, null))
ERROR at line 1:
ORA-20001: Postcode cannot be null!
ORA-06512: at "SCOTT.ADDRESS", line 18
ORA-06512: at line 1
SQL> A caveat: we cannot change the TYPE spec once it's in use. If we want to change the TYPE not only do we have to drop the TYPE BODY we also have to drop any TABLE that has a column defined as our TYPE. This limits the flexibility of abstract data type as data storage solution. Just make sure you get the signature right before going into production with it.
Also, of course, this doesn't solve your major aim, which was avoiding work. You are still going to have to turn all your address columns into an ADDRESS object. This can be done using Agent 355099's automation techniques but undermines the object (oh ho!) of the exercise.
In short: stick to relational columns with constraints for your data.
Cheers, APC