[42000][1064] SQL Error: Can't execute new table in DataGrip.

[42000][1064] SQL Error: Can't execute new table in DataGrip.

create table Users
(
    AttendeeID varchar not null,
    FRAG boolean null,
    FirstName string null,
    LastName string null,
    BadgeName varchar null,
    BadgeNumber int not null,
    DateOfBirth date null,
    EmailAddress int not null,
    Password password null,
    PrivacyPolicy boolean null,
    TermsConditions boolean null
);

create unique index Users_AttendeeID_uindex
   on Users (AttendeeID);

create unique index Users_BadgeNumber_uindex
    on Users (BadgeNumber);

create unique index Users_EmailAddress_uindex
   on Users (EmailAddress);

alter table Users
    add constraint Users_pk
        primary key (AttendeeID);

所以,我正在学习数据库,我正在为我的 dbms 使用 Datagrip,但是当我尝试执行它时,我收到了以下错误:

[42000][1064] You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'not null, FRAG boolean null, FirstName string null, LastName string null, Ba' at line 3.

本来代码读作not null,所以我把它改成了null,不明白是什么问题。我没有在以前的问题中找到答案,任何帮助都会很棒。谢谢

varchar 需要指定长度,例如 varchar(30) 30 个字符。

string 不是类型,请使用 varchar(LENGTH).

password 不是类型,请使用 varbinary(LENGTH),因为我假设您做的是正确的事情并使用加盐哈希。

我知道晚了,但我会写的:

CREATE TABLE Users
(
    AttendeeID CHAR(30) NOT NULL,
    FRAG ENUM('n', 'y') NOT NULL DEFAULT 'n',
    FirstName CHAR(50) NULL,
    LastName CHAR(50) NULL,
    BadgeName CHAR(100) NOT NULL,
    BadgeNumber CHAR(30) NOT NULL,
    DateOfBirth DATE NULL,
    EmailAddress CHAR(250) NOT NULL,
    Password CHAR(64) NOT NULL,
    PrivacyPolicy ENUM('n', 'y') NOT NULL DEFAULT 'n',
    TermsConditions ENUM('n', 'y') NOT NULL DEFAULT 'n',
    PRIMARY KEY (`AttendeeID`),
    UNIQUE KEY `Users_EmailAddress_uindex` (`EmailAddress`),
    UNIQUE KEY `Users_BadgeNumber_uindex` (`BadgeNumber`)
);

我使用 CHAR 而不是 VARCHAR 来提高性能,因为在这种情况下,对于数据库引擎来说,查找数据在数学上很容易,因为行将具有固定大小。

为了便于阅读,我使用 ENUM - 您以后也可以添加 not sure 作为第三个选择。
关于尺码: TINYINT(1) 并存储为一个字节的数据,ENUM('n','y') 也存储为一个字节的数据。

BadgeNumberCHAR 因为可能会有数字从 0 零开始的情况。喜欢:0000001023423 或者也许可以有业务任务来枚举客人,例如:G00001 - 所以对我来说,最好使用 CHAR 作为徽章编号。

此外,您可能有 UserBadges table 并将其与 Users table 相关联 - 如果某些用户可能有很多徽章,比如他丢失了旧徽章怎么办或者只是为了历史你会有 A case 的徽章 B case.

的徽章

按想法 User 和徽章是不同的实体。所以也得说明一下。

我敢肯定这些问题可能会迫使人们从一开始就让项目更加灵活。