3

是否有最接近这些示例之一的最佳实践？

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

绝对是个人喜好。我更喜欢在单个语句中尽可能多地做，CREATE TABLE因为我发现它更简洁。我需要的大部分东西都在那里描述。

有时这是不可能的。假设你有两个表，每个表都有引用，或者你想先加载一个包含一堆数据的表，所以你在加载表之后添加额外的索引。

您会发现许多从数据库创建模式的工具会将它们分开（主要是因为它总是正确的——定义所有表，然后定义所有关系）。

但就个人而言，如果可行的话，我发现将所有内容集中在一个地方是最好的。

于 2012-09-06T04:53:18.923 回答
5

在构建最终将由其他人稍后运行的部署脚本时，我更喜欢将脚本分开一点。如果出现问题，从日志中判断到底是什么失败会更容易一些。

我的表创建脚本通常只有 NOT NULL 约束。PK、unique 和 FK 约束将在之后添加。

不过，这是一个小问题，我并没有特别反对将它们全部组合到一个大的 CREATE TABLE 语句中。

您可能会发现您的工作场所已经制定了标准。例如，我当前的客户需要单独的 CREATE TABLE 脚本，然后需要更多单独的约束、索引等脚本。

当然，索引组织表是个例外，它必须预先声明 PK 约束。

于 2012-09-06T05:42:45.483 回答
0

在实际创建语句中为字段定义任何属性或默认值是个人偏好。我注意到的一件事是您的第二个语句不起作用，因为您没有指定 id 字段是NOT NULL.

我想我预先指定表的主键是可读性的个人最佳实践。

创建表时要考虑的另一件事是您希望如何识别项目，唯一性或复合性。 ALTER TABLE有利于事后创建复合键。

于 2012-09-06T04:34:36.850 回答