3

これらの例の 1 つに最も近いベスト プラクティスはありますか?

CREATE TABLE TABLE1 
(
ID   NUMBER(18)     CONSTRAINT TABLE1_PK PRIMARY KEY,
NAME VARCHAR2(10)   CONSTRAINT NAME_NN NOT NULL
);

また

CREATE TABLE TABLE1 
(
ID   NUMBER(18),
NAME VARCHAR2(10)   CONSTRAINT NAME_NN NOT NULL
);

ALTER TABLE TABLE1  ADD CONSTRAINT TABLE1_PK
PRIMARY KEY (ID)
USING INDEX (CREATE UNIQUE INDEX IDX_TABLE1_PK ON TABLE1 (ID));

一般的に、どちらのシナリオでもより良い結果が得られるでしょうか? 最初のオプションははるかに読みやすいですが、おそらく後者が望ましい理由があります。

4

3 に答える 3

5

後で誰かが実行する展開スクリプトを作成するときは、スクリプトをかなり分割することをお勧めします。何かがうまくいかない場合は、ログから正確に何が失敗したかを判断するのが少し簡単です。

私のテーブル作成スクリプトには通常、NOTNULL制約のみがあります。その後、PK、一意、およびFKの制約が追加されます。

ただし、これはマイナーなポイントであり、すべてを1つの大きなCREATETABLEステートメントに結合することに特に反対することはありません。

あなたの職場にはすでに基準が整っていることに気付くかもしれません。たとえば、現在のクライアントでは、CREATE TABLE用に個別のスクリプトが必要であり、次に制約やインデックスなど用にさらに個別のスクリプトが必要です。

もちろん、例外はインデックス編成テーブルであり、PK制約を事前に宣言する必要があります。

于 2012-09-06T05:42:45.483 に答える
5

間違いなく個人的な好み。CREATE TABLE私はそれがより簡潔であると思うという理由だけで、単一のステートメントでできる限り多くのことをすることを好みます。私が必要とするほとんどすべてがそこに記述されています。

時々それは不可能です。それぞれを参照する2つのテーブルがある場合、または最初に大量のデータを含むテーブルをロードする場合は、テーブルのロード後に追加のインデックスを追加するとします。

DBからスキーマを作成する多くのツールがそれらを分離します（ほとんどの場合、それは常に正しいためです。すべてのテーブルを定義してから、すべての関係を定義します）。

しかし、個人的には、実用的であれば、すべてを1か所にまとめることが最善だと思います。

于 2012-09-06T04:53:18.923 に答える
0

実際の create ステートメントでフィールドの属性またはデフォルトを定義するのは個人的な好みです。私が気づいたことの 1 つは、id フィールドが であると指定していないため、2 番目のステートメントが機能しないことですNOT NULL。

テーブルの主キーを前もって指定することは、読みやすさのための個人的なベスト プラクティスだと思います。

テーブルを作成する際に考慮すべきもう 1 つの点は、項目を一意に識別するか、複合的に識別するかということです。 ALTER TABLE事後に複合キーを作成するのに適しています。

于 2012-09-06T04:34:36.850 に答える