web-dev-qa-db-ja.com

`CREATE TABLE`ステートメントで制約を定義する

最近、Python web-framework called web2py によって構築された Database Abstraction Layer ）（ DAL構文についてはクリック ）_CREATE TABLE_ステートメント内に制約を含めるオプションが含まれています。

Stanford 's "Introduction to Databases" 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)
);
_

ところで、キーワードにはCAPS、テーブル名には上部のCamelCase、属性とトリガー名には下部のunder_scoreを使用しています。これは良い習慣ですか？ -私のインデントと空白の使用方法も批評してください:)

oracleoracle-11g-r2best-practicesconstraint
6
A T

エンタープライズレベルのデータベースでは、多くのデータを簡単に再読み込みできるように制約を分割するための良いケースを作ることができます。私は見た

  • ベアテーブル作成ステートメント
  • 候補キー（主キーを含む）、
  • 外部キー、
  • チェック制約、
  • 等.

これらはそれぞれ1つ以上のファイルに含まれます。これらのファイルはすべてバージョン管理下にあります。

理論的根拠は、大量のデータをロードしてthen大量のデータをロードするよりも高速であるということですafter制約とインデックスを宣言しました。 makefileでテキストを少し操作するだけで、すべての制約が含まれた「完全な」CREATE TABLEステートメントを生成できます。

6
Mike Sherrill 'Cat Recall'

個人的には好みの問題だと思います。

ALTERステートメントを使用して制約が定義されているスクリプトは、作成の順序を気にする必要がないため、少し柔軟性があります（最初にすべてのテーブル、次にすべてのPK、次にすべてのFK）。

ただし、制約が埋め込まれたスクリプトはより「自己完結型」です。制約の定義を見つけるために、スクリプトの他の場所を探す必要はありません。

キャメルケースを使用しても、すべて大文字に変換されるため、違いはありません（名前を引用するために"を使用しなかったため、これは良いことです）。

インデントと空白について：これもまた完全に個人的な好みです。 6か月経ってもまだ理解できると思う方法でやってください。最も重要なことは、一貫性を保つことです（そして、おそらくプロジェクトドキュメントのどこかにスタイルを文書化して、新しいメンバーが同じ書式を理解して使用できるようにします）。

7
a_horse_with_no_name