【问题标题】:SQL table not being created未创建 SQL 表
【发布时间】:2018-05-04 23:53:47
【问题描述】:

我正在使用 Oracle。

CREATE TABLE  "CUSTOMER" 
(  

"CUS_ID" VARCHAR2(9), 
    "CUSTOMER_NAME" VARCHAR2(30), 
    "EMAIL" VARCHAR2(30), 
    "BIRTH_DATE" DATE, 
    "Mobile_number" NUMBER (10),
    "Number_adopted" (number) (1);
     CONSTRAINT "CUSTOMER_PK" PRIMARY KEY ("CUS_ID")
     constraint "Email_uni" unique (EMAIL)
     constraint "Mobile_uni" unique (Mobile_number)
     constraint "adopted_range_ck" check ( Number_adopted >=1 and Number_adopted<=4)   USING INDEX  ENABLE
   );

我得到:

ORA-00902: 无效的数据类型

也在此表中:

CREATE TABLE  "ANIMAL" 
   (    "ANIMAL_ID" VARCHAR2(9), 
    "ANIMAL_NAME" VARCHAR2(30),
    "AGE" NUMBER(2),
    "ANIMAL_TYPE" VARCHAR2(30),
    "EXPENCES" NUMBER (10),
    "ADOPTED" VARCHAR2(9),

     CONSTRAINT "ANIMAL_PK" PRIMARY KEY ("ANIMAL_ID")
     CONSTRAINT "ANIMAL_EXP_ck check" ( EXPENCES >=1 and EXPENCES<=1000)
     CONSTRAINT "ANIMAL_AGE_ck check" ( AGE >=1)
  USING INDEX  ENABLE
   );

我收到缺少右括号的错误,但我无法解决这个问题。

【问题讨论】:

  • 你的 DBMS 是什么?
  • 它是 APEX 甲骨文
  • Oracle是DBMS,APEX是UI开发工具,本题不涉及。
  • "Mobile_number""Number_adopted" 被强制混合大小写而其他所有名称都不区分大小写的意义是什么?双引号标识符用于特殊情况,而不是常规的表创建。
  • 在询问之前,至少要努力寻找解决方案。在这种情况下,您可以从具有单列的表开始。在它工作之后,添加另一列,添加想法,添加约束。

标签: sql oracle create-table


【解决方案1】:

"Number_adopted" (number) (1) 后面有一个;number 周围的括号在这里也是错误的。然后你忘记了约束后的,。如果您在名称周围定义了带有" 的列并且名称不是全部大写,则各个字符的大小写必须在进一步的引用中匹配,并且这些也必须包含在" 中。这就是为什么您的constraint "Mobile_uni" unique (Mobile_number) 必须更改为constraint "Mobile_uni" unique ("Mobile_number")。 (但您可能首先要修改它并让列名全部大写。经验告诉我,这样的事情是未来的陷阱,因为您必须在任何查询等中准确使用该名称,它是很难注意到让一个人想知道为什么事情不工作。)我猜那个USING INDEX ENABLE放错了位置。

CREATE TABLE  "CUSTOMER" 
(  

"CUS_ID" VARCHAR2(9), 
    "CUSTOMER_NAME" VARCHAR2(30), 
    "EMAIL" VARCHAR2(30), 
    "BIRTH_DATE" DATE, 
    "Mobile_number" NUMBER (10),
    "Number_adopted" number (1), -- delete ( ) ; add ,
     CONSTRAINT "CUSTOMER_PK" PRIMARY KEY ("CUS_ID") USING INDEX  ENABLE, --  add ,
     constraint "Email_uni" unique (EMAIL), --  add ,
     constraint "Mobile_uni" unique ("Mobile_number"), -- add ,  " "
     constraint "adopted_range_ck" check ( "Number_adopted" >=1 and "Number_adopted"<=4) -- move USING INDEX  ENABLE add " "
   );

在第二个中,您还忘记了约束后的,,并且将USING INDEX ENABLE 放错了位置。您还错放了检查约束的 " 并意外地将关键字 CHECK 包含在其中。

CREATE TABLE  "ANIMAL" 
   (    "ANIMAL_ID" VARCHAR2(9), 
    "ANIMAL_NAME" VARCHAR2(30),
    "AGE" NUMBER(2),
    "ANIMAL_TYPE" VARCHAR2(30),
    "EXPENCES" NUMBER (10),
    "ADOPTED" VARCHAR2(9),

     CONSTRAINT "ANIMAL_PK" PRIMARY KEY ("ANIMAL_ID") USING INDEX  ENABLE, -- add ,
     CONSTRAINT "ANIMAL_EXP_ck" check ( EXPENCES >=1 and EXPENCES<=1000), -- add , move "
     CONSTRAINT "ANIMAL_AGE_ck" check ( AGE >=1) -- move "
  -- move USING INDEX  ENABLE
   );

【讨论】:

  • 非常感谢,还有一个问题。我应该将 using INDEX ENABLE 移到哪里?
  • @Fido Dido:欢迎。我在主键之后移动了它。参见我上面的代码 sn-ps。
【解决方案2】:

我总是会在对应的列中定义单列约束。

此外,双引号标识符只是错误和不便的来源,除非您有特定原因确实需要非标准名称。将它们与全大写名称一起使用是没有意义的,因为这已经是默认设置了,所以你只是打开了错误潜入的可能性,例如如果您不小心将一列命名为 "ANIMAL TYPE",而您的意思是 "ANIMAL_TYPE"。通常最好避免使用双引号。

using index 子句用于为唯一键或主键指定非默认索引属性(指定表空间、压缩选项等)。由于您使用的是默认值,因此您不需要它。

enable 关键字也是默认关键字,因为除非您另外指定,否则在启用状态下创建约束,因此您不需要它。

between 关键字在指定包含范围时可以节省大量输入。

无需以大写形式编码任何内容。我不知道为什么它如此普遍。个人认为是错误的。

create table  customer 
( cus_id          varchar2(9)   constraint customer_pk primary key
, customer_name   varchar2(30)
, email           varchar2(30)  constraint email_uni unique
, birth_date      date
, mobile_number   number(10)    constraint mobile_uni unique
, number_adopted  number(1)     constraint adopted_range_ck check (number_adopted between 1 and 4) 
);

create table animal 
( animal_id       varchar2(9)   constraint animal_pk primary key
, animal_name     varchar2(30)
, age             number(2)     constraint animal_age_ck check (age >= 1)
, animal_type     varchar2(30)
, expenses        number (10)   constraint animal_exp_ck check (expenses between 1 and 1000)
, adopted         varchar2(9)
);

【讨论】:

    猜你喜欢
    • 2021-09-29
    • 2018-03-19
    • 1970-01-01
    • 1970-01-01
    • 2021-08-01
    • 2019-04-27
    • 1970-01-01
    • 1970-01-01
    • 2021-07-17
    相关资源
    最近更新 更多