Question

我的初始有缺陷的逻辑

任何熟悉建立数据库，创建表格等等的人都能立即看到我最初的数据库建立逻辑，这是完全有缺陷和不好的做法。下面有一些片段;

产品
- 音乐
  - ...
- 书籍
  - ...
- 游戏
  - Console_Games
    - 开发
      - ID
      - 名称
      - 网站
    - 制造商
      - ID
      - 名称
      - 网站
    - 出版商
      - ID
      - 名称
      - 网站
    - 流派
    - 平台
      - ID
      - 平台
      - 概述
      - 开发
      - 制造商
      - ....

经过一番研究......

我现在理解一个数据库文件根类似于结构不是前进的方式，而是在根目录下有多个表，所以这样说;

Console_Games_Developers - 表格
- ID - int NOT NULL
- 名称 - varchar（255）
- 网站 - varchar（255）
Console_Games_Manufacturers-表
- ID - int NOT NULL
- 名称 - varchar（255）
- 网站 - varchar（255）
Console_Games_Publishers - 表格
- ID - int NOT NULL
- 名称 - varchar（255）
- 网站 - varchar（255）

生成的SQL查询

CREATE TABLE User_Interests
(
        UserID int NOT NULL,
        MovieInterests TEXT,
        TVShowInterests TEXT,
        BookInterests TEXT,
        MusicInterests TEXT,
        PRIMARY KEY (UserID)
);
CREATE TABLE Game_Developers
(
        GameDevID int NOT NULL,
        Name varchar(255),
        Website varchar(255),
        PRIMARY KEY (GameDevID)
);
CREATE TABLE Game_Manufacturers
(
        GameManufactID int NOT NULL,
        Name varchar(255),
        Website varchar(255),
        PRIMARY KEY (GameManufactID)
);
CREATE TABLE Game_Publishers
(
        GamePublisherID int NOT NULL,
        Name varchar(255),
        Website varchar(255),
        PRIMARY KEY (GamePublisherID)
);

细节 - 问题

如何实现这样的数据库
- 好的，所以我已经添加了我尝试/研究过的东西，但是我不知道这是否真的是正确的前进方式？
我使用的是正确的标识符吗？
- 当我使用“标识符”这个词时，我的意思是喜欢的; int NOT NULL和varchar（255）。

Answer 1

这可能会让你开始：

产品类型：这可能是游戏，电影，书籍或音乐

create table Product_Type( id INT, description VARCHAR( 1024 ), ... )

产品子类型：这可能是控制台游戏

create table Product_Sub_Type( id INT, description VARCHAR( 1024 ), product_type_id, ... )

Relation_Type这将是产品的开发者或制造商

create table Relation_Type( id INT, description VARCHAR( 1024 ), ... )

关系：这是开发人员，制造商等关系的原型

create table Relation( id INT, description VARCHAR( 1024 ), relation_type_id INT, ... )

Relation_Info_type：网站，名称，地址等信息类型

create table Relation_Info_Type( id INT, description VARCHAR( 1024 ), ... )

Relation_Info：这可以是姓名，地址或网站。（如果该关系有多个地址或网站）

create table Relation_Info( id INT, relation_id INT, relation_info_type_id INT, description VARCHAR( 1024 ), ... )

Product_Relation：这是将关系与产品联系起来的多对多方式，例如：开发商和制造商。

create table product_relation( id INT, relation_id INT, product_id INT, relation_info_type_id INT, description VARCHAR( 1024 ), ... )

为了保持简单（和灵活），您可以为流派（复古，动作，冒险，拼图）做同样的事情：接下来是多对多表格，如

create table genre( id INT, description VARCHAR( 1024 ), ... )
create product_genre( id INT, product_id INT, genre_id INT, ... )

对于平台（Windows，IOS，Ubuntu，Android）：

create table platform( id INT, description VARCHAR( 1024 ), overview VARCHAR( 4096 ), developer_id, manufacturer_id,... )
create table platform_product( id INT, platform_id, product_id, ... )

这些产品类似于Interstellar或Final Fantasy VII游戏

create table Products ( id INT, description VARCHAR( 1024 ), product_sub_type_id INT, ... )

所有[name] _id列应该被理解为与表[name]具有外键关系，但引用表Relation的developer_id和manufacturer_id除外。

Answer 2

这不是一个正确的答案，但结果太久了......

在不了解您的业务需求和约束的情况下，很难对模型的有效性说多少，但请记住关系模型的一个目标是避免数据重复，因此请考虑如何存储数据的数据公司既是开发商，也是开发商。制造商和出版的游戏机游戏，同时它还出版了与游戏特许经营相关的书籍以及他们开发的游戏的配乐。（也许他们也做PC / Mac游戏......）。

标识符的使用看起来还不错 - 如果您选择将游戏开发人员标识为Game_Publishers.GamePublisherID或仅Game_Publishers.ID，那么这主要是风格问题。尽管如此，识别name属性不是not null

User_Interests表似乎可以使用一些重新构建，但同样，不清楚你的需求是什么 - 但是名为MovieInterests的列表明你打算在其中存储多个值 - 也许是一系列兴趣，如果是这样的话，这会破坏正常的形式，导致一团糟，后来会后悔。

正确建立我的数据库表

我的初始有缺陷的逻辑

经过一番研究......

生成的SQL查询

细节 - 问题

2 个答案: