Definindo restrições nas instruções `CREATE TABLE`

Recentemente, tenho usado uma camada de abstração de banco de dados criada por uma estrutura da web Python chamada web2py ( clique para obter a sintaxe DAL ). Eles incluem a opção de incluir suas restrições na CREATE TABLEinstrução.

Enquanto tomava o MOOC "Introduction to Databases" de Stanford , o SQL Standard foi mencionado como suportando qualquer consulta dentro da instrução como restrições (essencialmente substituindo um caso de uso importante para gatilhos).CREATE TABLE

Qual é a melhor prática?

Abaixo está um exemplo simples de inclusão de restrições em CREATE TABLEinstruções; em vez de através de ALERT TABLEe/ou CREATE TRIGGERdeclarações:

CREATE TABLE Place (
    address VARCHAR2(40),
    CONSTRAINT place_pk
        PRIMARY KEY (address)
);

CREATE TABLE Company (
    c_name VARCHAR2(40),
    CONSTRAINT company_pk
        PRIMARY KEY (c_name)
);

CREATE TABLE Employee (
    e_name VARCHAR2(40),
    tax_no NUMBER,
    salary NUMBER(19,4),
    sex CHAR,
    birthdate DATE,
    address VARCHAR2(40),
    CONSTRAINT employee_pk
        PRIMARY KEY (tax_no),
    CONSTRAINT address_fk
        FOREIGN KEY (address) REFERENCES Place(address),
    CHECK (address IS NOT NULL)
);

CREATE TABLE CompanyEmployee (
    employee_id NUMBER,
    company_id VARCHAR2(40),
    CONSTRAINT unique_employee_id
        UNIQUE(employee_id),
    CONSTRAINT employee_id_fk
        FOREIGN KEY (employee_id) REFERENCES Employee(tax_no),
    CONSTRAINT company_id_fk
        FOREIGN KEY (company_id) REFERENCES Company(c_name),
    CONSTRAINT company_employees_pk
        PRIMARY KEY (employee_id, company_id)
);

BTW: Você notará que estou usando CAPS para palavras-chave, CamelCase maiúsculo para nomes de tabelas e under_score inferior para nomes de atributos e gatilhos. Isso é uma boa prática? - Sinta-se à vontade para criticar meus estilos de recuo e uso de espaços em branco também :)