数据库设计 - 不知名站点

# videos：

```sql
CREATE TABLE videos (
    bvid CHAR(50) PRIMARY KEY,        -- 视频的唯一标识符
    pic CHAR(200),                    -- 视频的封面图像URL
    title CHAR(200),                  -- 视频标题
    ownerid CHAR(50),                 -- 视频拥有者的ID
	p int(4), -- 分p
    rotate TINYINT,                   -- 视频的旋转角度，1位小整数
    pubdate TIMESTAMP,                -- 视频的发布时间戳
    describes TEXT                       -- 视频描述，使用TEXT类型存储较长的描述
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
```

### 表的文档说明：

| 字段名   | 数据类型   | 长度    | 描述                                                         |
|----------|------------|---------|--------------------------------------------------------------|
| bvid     | CHAR       | 50      | 视频的唯一标识符（BVID），用于标识每个视频。                     |
| pic      | CHAR       | 200     | 视频的封面图像URL，存储指向视频封面图的URL地址。               |
| title    | CHAR       | 200     | 视频的标题，存储视频的名称或主题。                             |
| ownerid  | CHAR       | 50      | 视频上传者的ID，标识视频所有者的唯一标识符。                   |
| width    | INT        | 4       | 视频的宽度，4位整数，表示视频播放时的宽度。                     |
| height   | INT        | 4       | 视频的高度，4位整数，表示视频播放时的高度。                     |
| rotate   | TINYINT    | 1       | 视频的旋转角度，表示视频是否需要旋转（例如：0表示不旋转，90表示顺时针旋转90度）。 |
| pubdate  | TIMESTAMP  | -       | 视频的发布时间戳，存储视频的上传时间。                         |
| `desc`   | TEXT       | -       | 视频的描述，存储视频的简短描述信息，可以为空。                 |

### 注意事项：
- 使用 `CHAR` 类型来存储固定长度的字段，如 `bvid`、`pic`、`title` 和 `ownerid`，可以保证字段长度一致。
- `width` 和 `height` 使用 `INT(4)` 来存储视频的分辨率。
- `rotate` 字段使用 `TINYINT`，是否竖屏。
- `pubdate` 字段使用 `TIMESTAMP` 类型，时间戳操作。
- `desc` 字段使用 `TEXT` 类型，以便存储较长的文本数据。

# owner
以下是创建 `owner` 表的 MySQL SQL 代码及文档说明：

### SQL 代码

```sql
CREATE TABLE `owner` (
  `ownerid` CHAR(50) NOT NULL,            -- 主键: 唯一标识每个owner，长度50
  `face` CHAR(200) NOT NULL,             -- face: 存储owner的面部特征或图像链接，长度200
  `name` CHAR(50) NOT NULL,              -- name: owner的名称，长度50
  `describes` TEXT,                      -- describes: owner的描述信息，可存储较长的文本
  PRIMARY KEY (`ownerid`)                -- 设置ownerid为主键
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;  -- 使用InnoDB引擎和utf8mb4字符集
```

### 表结构说明

- `ownerid`：主键，长度为 50 的字符型数据，用来唯一标识每个 `owner`。
- `face`：长度为 200 的字符型数据，存储与 `owner` 相关的面部特征或图像链接。
- `name`：长度为 50 的字符型数据，存储 `owner` 的名称。
- `describes`：`TEXT` 类型，用来存储对 `owner` 的描述信息，支持更长的文本内容。

### 字段描述

1. **ownerid**：此字段用作每个 `owner` 的唯一标识符，是 `PRIMARY KEY`。根据实际应用，可能会使用 UUID 或其他唯一值生成策略。
2. **face**：用于存储与 `owner` 相关的图像链接
3. **name**：存储 `owner` 的姓名或标识，可以是实际姓名或其他形式的标识。
4. **describes**：用于存储关于 `owner` 的额外描述信息。使用 `TEXT` 类型，以支持较长的文本。

根据提供的数据，`stat` 表可以用来存储某个对象的统计信息。以下是 `stat` 表的创建 SQL 代码和文档说明。

# stat

```sql
CREATE TABLE `stat` (
  `aid` BIGINT NOT NULL,               -- aid: 唯一标识每个对象（例如视频、文章等）的ID
  `view` INT NOT NULL DEFAULT 0,       -- view: 观看次数
  `danmaku` INT NOT NULL DEFAULT 0,    -- danmaku: 弹幕数量
  `reply` INT NOT NULL DEFAULT 0,      -- reply: 回复数量
  `favorite` INT NOT NULL DEFAULT 0,   -- favorite: 收藏数量
  `coin` INT NOT NULL DEFAULT 0,       -- coin: 硬币数量
  `share` INT NOT NULL DEFAULT 0,      -- share: 分享次数
  `now_rank` INT NOT NULL DEFAULT 0,   -- now_rank: 当前排名
  `his_rank` INT NOT NULL DEFAULT 0,   -- his_rank: 历史排名
  `like` INT NOT NULL DEFAULT 0,       -- like: 点赞数量
  `dislike` INT NOT NULL DEFAULT 0,    -- dislike: 不喜欢数量
  PRIMARY KEY (`aid`)                 -- aid 作为主键，确保每个对象唯一
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;  -- 使用 InnoDB 引擎和 utf8mb4 字符集
```

### 表结构说明

- `aid`：大整数型（`BIGINT`），作为对象的唯一标识符，可能表示视频、文章或其他类型的对象。此字段是表的主键。
- `view`：整数型（`INT`），表示对象的观看次数。
- `danmaku`：整数型（`INT`），表示与对象相关的弹幕数量。
- `reply`：整数型（`INT`），表示与对象相关的回复数量。
- `favorite`：整数型（`INT`），表示对象的收藏数量。
- `coin`：整数型（`INT`），表示与对象相关的硬币数量。
- `share`：整数型（`INT`），表示对象被分享的次数。
- `now_rank`：整数型（`INT`），表示当前的排名。
- `his_rank`：整数型（`INT`），表示历史排名。
- `like`：整数型（`INT`），表示对象的点赞数量。
- `dislike`：整数型（`INT`），表示对象的不喜欢数量。

### 字段默认值

- `view`, `danmaku`, `reply`, `favorite`, `coin`, `share`, `like`, `dislike` 都有默认值 `0`，表示没有数据时字段默认为0。
- `now_rank` 和 `his_rank` 也默认值为 `0`，表示排名未定义或未计算。

# 合集表
```
CREATE TABLE collections (
    collection_id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
);
```
```
CREATE TABLE video_collections (
    bvid INT,
    collection_id INT,
    PRIMARY KEY (bvid, collection_id),
    FOREIGN KEY (bvid) REFERENCES videos(bvid) ON DELETE CASCADE,
    FOREIGN KEY (collection_id) REFERENCES collections(collection_id) ON DELETE CASCADE
);
```

这段 SQL 语句定义了一个名为 `video_collections` 的表，它用于表示视频（`bvid`）和合集（`collection_id`）之间的多对多关系。下面是具体解释：

### 1. 表结构
```sql
CREATE TABLE video_collections (
    bvid INT,
    collection_id INT,
    PRIMARY KEY (bvid, collection_id),
    FOREIGN KEY (bvid) REFERENCES videos(bvid) ON DELETE CASCADE,
    FOREIGN KEY (collection_id) REFERENCES collections(collection_id) ON DELETE CASCADE
);
```

#### 1.1 `bvid INT`
- 这是视频表中的主键（假设视频表中的主键字段名为 `bvid`）。它用于存储视频的唯一标识符。
- `bvid` 在 `video_collections` 表中作为外键，引用了 `videos` 表中的 `bvid` 字段。

#### 1.2 `collection_id INT`
- 这是合集表中的主键（假设合集表中的主键字段名为 `collection_id`）。它用于存储合集的唯一标识符。
- `collection_id` 在 `video_collections` 表中作为外键，引用了 `collections` 表中的 `collection_id` 字段。

### 2. 主键（Primary Key）
```sql
PRIMARY KEY (bvid, collection_id)
```
- 这表示 `video_collections` 表的主键由两个字段组成：`bvid` 和 `collection_id`。
- 组合主键的作用是确保在 `video_collections` 表中，每个视频（`bvid`）和合集（`collection_id`）的组合是唯一的。也就是说，一个视频不能重复出现在同一个合集里。

### 3. 外键约束（Foreign Keys）
```sql
FOREIGN KEY (bvid) REFERENCES videos(bvid) ON DELETE CASCADE,
FOREIGN KEY (collection_id) REFERENCES collections(collection_id) ON DELETE CASCADE
```
- **`FOREIGN KEY (bvid) REFERENCES videos(bvid)`**：这是一个外键约束，表示 `video_collections` 表中的 `bvid` 字段引用了 `videos` 表中的 `bvid` 字段，确保 `video_collections` 表中的 `bvid` 必须是 `videos` 表中已经存在的一个 `bvid`。
- **`FOREIGN KEY (collection_id) REFERENCES collections(collection_id)`**：这是另一个外键约束，表示 `video_collections` 表中的 `collection_id` 字段引用了 `collections` 表中的 `collection_id` 字段，确保 `video_collections` 表中的 `collection_id` 必须是 `collections` 表中已经存在的一个 `collection_id`。

- **`ON DELETE CASCADE`**：这是外键的删除规则。表示如果 `videos` 表中的某个视频（`bvid`）被删除，或者 `collections` 表中的某个合集（`collection_id`）被删除，`video_collections` 表中所有引用该视频或合集的记录都会被自动删除。这确保了数据的一致性，避免了孤立数据的产生。