Mysql 课程代码的适当数据类型是什么？

好的，我被要求准备一个大学数据库，我被要求以某种方式存储某些数据。 例如，我需要存储一个课程代码，它有一个字母，后跟两个整数。例如I45、D61等。 所以应该是VARCHAR（3）对吗？但我仍然不确定这是否是正确的道路。我也不确定如何在SQL脚本中强制执行这一点。 在我的笔记中，我似乎找不到任何答案，我目前正在为这个问题编写数据字典，然后再插手脚本

---

有什么建议吗？

尽可能使主键没有商业意义。您可以轻松地更改数据库设计，而不会严重影响应用程序层。使用哑主键，用户不会将意义与特定记录的标识符相关联

您所查询的内容被称为智能钥匙，它通常是用户可见的。非用户可见键称为哑键或代理键，有时此非用户可见键变为可见键，但这不是问题，因为大多数哑键不由用户解释。例如，尽管您希望更改此问题的标题，但此问题的id将保持不变

使用智能主键，有时出于美观的原因，用户希望指定键的格式和外观。而且这可以很容易地得到经常更新，因为用户觉得。这将是应用程序端的一个问题，因为这需要在相关表上级联更改；数据库端也是如此，因为相关表上键的级联更新非常耗时

请在此处阅读详细信息：

---

代理密钥的优点：

您可以在代理密钥（又称哑密钥）旁边实现自然密钥（又称智能密钥）

这种方法的优点是，当学校在未来的某个时候扩张，然后他们决定提供一种西班牙语的数据库结构时，您的数据库与用户引入的用户解释值隔离

假设您的数据库开始使用智能密钥：

create table course
(
    course_code primary key, -- natural key. what's seen by users e.g. 'D61'

    course_name text unique, -- e.g. 'Database Structure'
    date_offered date
);

然后是西班牙语的数据库结构课程。如果用户向您的系统介绍了他们自己的规则，他们可能会在课程代码值中输入以下内容： D61/ESP，其他人将以ESP-D61，ESP:D61的方式进行。如果用户决定自己的主键规则，那么事情可能会失控，然后他们会告诉您根据他们在主键格式上创建的任意规则查询数据，例如“列出我们学校提供的所有西班牙语课程”，epic要求不是吗？那么，一个好的开发人员应该做些什么来适应数据库设计的这些变化呢？他/她将对数据结构进行形式化，其中一人将根据以下内容重新设计表格：

create table course
(
    course_code text, -- primary key
    course_language text, -- primary key

    course_name text unique,
    date_offered date,

    constraint pk_course primary key(course_code, course_language)
);

你看到问题了吗？这将导致停机，因为您需要将更改传播到依赖于该课程表的表的外键。当然，您还需要首先调整这些依赖表。看看它不仅会给DBA带来什么麻烦，也会给开发人员带来什么麻烦

如果您从一开始就使用哑主键，即使用户在您不知道的情况下向系统引入规则，这也不会导致对数据库设计进行任何大规模数据更改或数据模式更改。这可以为您赢得相应调整应用程序的时间。然而，如果您将智能放在主键中，像上面这样的用户需求可以使您的主键自然地转移到复合主键。这不仅在数据库设计、重新构造和大量更新数据方面很困难，而且在应用程序快速适应新的数据库设计方面也很困难

create table course
(
    course_id serial primary key,
    course_code text unique, -- natural key. what's seen by users e.g. 'D61'
    course_name text unique, -- e.g. 'Database Structure'
    date_offered date
);

因此，使用代理键，即使用户在课程代码中隐藏了新的规则或信息，您也可以安全地将更改引入表中，而无需强迫您快速调整应用程序以适应新的设计。您的应用程序仍然可以继续，不需要停机。它真的可以为你赢得时间，随时调整你的应用程序。这将是对特定语言课程的更改：

create table course
(
    course_id serial primary key,

    course_code text, -- natural key. what's seen by users e.g. 'D61'
    course_language text, -- natural key. what's seen by users e.g. 'SPANISH'

    course_name text unique, -- e.g. 'Database Structure in Spanish'
    date_offered date,

    constraint uk_course unique key(course_code, course_language)
);

如您所见，您仍然可以执行一个大规模的

UPDATE

语句，将用户在课程代码上强加的规则拆分为两个字段，而不需要对依赖表进行更改。如果使用智能复合主键，重新构造数据将迫使您将复合主键上的更改级联到从属表的复合外键。使用dumb主键，您的应用程序仍将正常运行，您可以在以后的任何时间根据新设计（例如，课程语言的新文本框）修改对应用程序的更改。对于哑主键，依赖表不需要复合外键来指向课程表，它们仍然可以使用相同的旧哑/代理主键

---

而且，使用哑主键时，主键和外键的大小将不会尽可能地扩大，使主键没有业务意义。您可以轻松地更改数据库设计，而不会严重影响应用程序层。使用哑主键，用户不会将意义与特定记录的标识符相关联

您所查询的内容被称为智能钥匙，它通常是用户可见的。非用户可见键称为哑键或代理键，有时此非用户可见键变为可见键，但这不是问题，因为大多数哑键不由用户解释。例如，尽管您希望更改此问题的标题，但此问题的id将保持不变

使用智能主键，有时出于美观的原因，用户希望指定键的格式和外观。而且这可以很容易地得到经常更新

create table course
(
    course_id serial primary key,

    course_code text, -- natural key. what's seen by users e.g. 'D61'
    course_language text, -- natural key. what's seen by users e.g. 'SPANISH'

    course_name text unique, -- e.g. 'Database Structure in Spanish'
    date_offered date,

    constraint uk_course unique key(course_code, course_language)
);

set search_path='tmp';

DROP DOMAIN coursename CASCADE;
CREATE DOMAIN coursename AS varchar NOT NULL
    CHECK (length(value) > 0
    AND  SUBSTR(value,1) >= 'A' AND SUBSTR(value,1) <= 'Z'
    AND  SUBSTR(value,2) >= '0' AND SUBSTR(value,2) <= '9' )
    ;

DROP TABLE course CASCADE;
CREATE TABLE course
    ( cname coursename PRIMARY KEY
    , ztext varchar
    , UNIQUE (ztext)
    );
INSERT INTO course(cname,ztext) 
  VALUES ('A11', 'A 11' ), ('B12', 'B 12' ); -- Ok
INSERT INTO course(cname,ztext)
  VALUES ('3','Three' ), ('198', 'Butter' ); -- Will fail