在“CREATE TABLE”语句中定义约束

A T*_*A T 6 oracle constraint best-practices oracle-11g-r2

最近我一直在使用一个由名为web2py的 Python 网络框架构建的数据库抽象层点击他们的 DAL 语法)。它们包括在语句中包含您的约束的选项。CREATE TABLE

在使用斯坦福大学“数据库简介”MOOC 时,有人提到SQL 标准支持CREATE TABLE语句中的任何查询作为约束(基本上取代触发器的主要用例)。

什么是最佳实践?

以下是在CREATE TABLE语句中包含约束的简单示例;而不是通过ALERT TABLE和/或CREATE TRIGGER声明:

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)
);
Run Code Online (Sandbox Code Playgroud)

顺便说一句:您会注意到,我使用大写字母作为关键字,大写 CamelCase 用于表名,而更低的 under_score 用于属性和触发器名称。这是好的做法吗?- 也可以随意批评我的缩进和空格使用风格:)

a_h*_*ame 7

我个人认为这是一个品味问题。

通过ALTER语句定义约束的脚本更加灵活,因为您不需要关心创建顺序(首先创建所有表,然后创建所有 PK,然后所有 FK)。

然而,带有嵌入式约束的脚本更加“独立”。您不需要在脚本中寻找其他位置来查找约束定义。

使用驼峰式大小写没有任何区别,因为无论如何所有内容都将转换为大写(因为您没有使用"引用您的名字 - 这是一件好事)。

关于缩进和空格:这完全是个人品味。按照你认为你在 6 个月后仍然可以理解的方式去做。最重要的是保持一致(并且可能在项目文档的某处记录您的风格,以便新成员可以理解并使用相同的格式)

  • +1 @AT 要回答您问题的另一部分,请不要在约束条件下使用触发器。 (2认同)

Mik*_*ll' 6

在企业级数据库中,您可以很好地拆分约束,以便更轻松地重新加载大量数据。我见过

  • 裸创建表语句
  • 候选键(包括主键),
  • 外键,
  • 检查约束,
  • 等等。

每一个都在一个或多个文件中。所有这些文件都在版本控制之下。

基本原理是加载大量数据然后应用约束比在声明约束和索引加载大量数据更快。通过在 makefile 中进行少量文本操作,您仍然可以生成包含所有约束的“完整”CREATE TABLE 语句。