正确建立我的数据库表

Question

我最初的有缺陷的逻辑

任何对建立数据库、创建表等有点熟悉的人都会立即能够看到我建立数据库的初始逻辑，这是完全有缺陷和不好的做法。下面有点sn-p；

• 产品
  • 音乐
    • ...
  • 书籍
    • ...
  • 游戏
    • Console_Games
      • 开发人员
        • 身份证
        • 姓名
        • 网站
      • 制造商
        • 身份证
        • 姓名
        • 网站
      • 出版商
        • 身份证
        • 姓名
        • 网站
      • 流派
      • 平台
        • 身份证
        • 平台
        • 概述
        • 开发者
        • 制造商
        • ....

经过一番研究……

我现在了解到，数据库文件根类结构不是前进的方向，而是在根目录下有多个表，可以这么说；

• 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)
);

细节 - 问题

1. 如何实现这样的数据库
   • 好的，所以我已经添加了我尝试/研究的内容以及诸如此类的内容，但是我不知道这实际上是否是正确的前进方式？
2. 我是否使用了正确的标识符？
   • 当我使用“标识符”这个词时，我的意思是这样的； 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, ... )

这些是诸如星际移动或游戏最终幻想 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 的列表明您打算在其中存储多个值 - 可能是一个数组兴趣，如果是这样，这将打破正常形式，导致一团糟，以后会后悔。