php - 在 MySql 中创建具有许多外键的大表

Question

我正在创建一个应用程序，我必须在其中保存有关用户教育的信息然后我会把它展示给他们看。每个用户可能有 1 个、2 个或更多个教育背景。我正在使用 laravel 架构生成器创建此表。这是代码

    Schema::create('educations', function (Blueprint $table) {
        $table->increments('id');
        $table->integer('user_id')->unsigned();
        $table->date('from')->nullable();
        $table->date('to')->nullable();
        $table->integer('country_id')->unsigned();
        $table->integer('city_id')->unsigned();
        $table->integer('university_id')->unsigned();
        $table->integer('faculty_id')->unsigned()->nullable();
        $table->integer('speciality_id')->unsigned()->nullable();
        $table->integer('degree_id')->unsigned()->nullable();
        $table->string('image', 100)->nullable();
        $table->text('additional')->nullable();


        $table->index('university_id');
        $table->index('faculty_id');
        $table->index('country_id');
        $table->index('city_id');
        $table->index('degree_id');
        $table->index('speciality_id');


        $table->foreign('user_id')
            ->references('id')->on('users')
            ->onDelete('cascade');

        $table->foreign('faculty_id')
            ->references('id')->on('faculties')
            ->onDelete('cascade');

        $table->foreign('degree_id')
            ->references('id')->on('degrees')
            ->onDelete('cascade');

        $table->foreign('speciality_id')
            ->references('id')->on('specialities')
            ->onDelete('cascade');

        $table->foreign('university_id')
            ->references('id')->on('universities')
            ->onDelete('cascade');

        $table->foreign('country_id')
            ->references('id')->on('countries')
            ->onDelete('cascade');

        $table->foreign('city_id')
            ->references('id')->on('cities')
            ->onDelete('cascade');
    });

MySql 代码:

CREATE TABLE `educations` 
( 
    `id`            INT UNSIGNED NOT NULL auto_increment PRIMARY KEY, 
    `user_id`       INT UNSIGNED NOT NULL, 
    `from`          DATE NULL, 
    `to`            DATE NULL, 
    `country_id`    INT UNSIGNED NOT NULL, 
    `city_id`       INT UNSIGNED NOT NULL, 
    `university_id` INT UNSIGNED NOT NULL, 
    `faculty_id`    INT UNSIGNED NULL, 
    `speciality_id` INT UNSIGNED NULL, 
    `degree_id`     INT UNSIGNED NULL, 
    `image`         VARCHAR(100) NULL, 
    `additional`    TEXT NULL 
) 

DEFAULT CHARACTER SET utf8mb4 COLLATE 'utf8mb4_unicode_ci') 

所以我有一个问题:当我想要获得一个用户的所有教育时，我必须在几乎 7 个表上运行 join 或使用 laravel 查询生成器并在页面加载时运行许多查询。我的数据库设计正确吗？

我在每一列上使用外键的原因是用户必须从我的可变数据库列表中选择他们的院系、大学、专业等。

任何答案都会有帮助。谢谢..

Answer 1

I believe I can see your idea behind these relational structures but in my humble opinion, they are not quite correct because I feel like in some cases the column entries are not directly related with each other. I will give you some examples:

1. Your table name is 'educations'. 1 user has got several educations but 1 education is not only reserved for 1 user. So this is an n:m-relation, which is why you need 1 table called 'educations', 1 for 'users' and 1 table in between those called 'user_has_got_education', for example. Your foreign keys land in the latter table with user_id and education_id.
2. country_id, city_id, university_id, faculty_id have got no direct relation to educations. Create a table called 'countries'(country_id, country_name, country_population, country_code,.....), then create a table called 'cities' in the same way. Here it gets a bit more difficult because one city_id is not necessarily distinct as there could be TWO city_ids with the city_name='London', one referring to London(UK), one to London(USA, Ohio) and one to London(USA, Kentucky). So what you need here is at least a table relation to 'countries' AND a state/county/shire - and even that might not be enough (if there were 2 cities called 'London' in the USA in Ohio state, for example). I call this 'direct relations'. In short, your columns (foreign keys) are in the wrong place, they belong into a 'directly connected brother table', not > into a 'nephew table'.

Try to get from one logical direct relation to another and 'connect' your tables accordingly. I hope I could help a bit, can't really give you a full table structure here, though.