Mysql and java multi-table join service optimization?

thinking about doing homework. If there is such a check-in system

Design according to the paradigm

College schedule
course schedule (College schedule one to many)
teacher schedule
Student schedule
Teaching schedule (teacher schedule many to many)
lesson schedule (Student schedule one to many)
course schedule (one to many)
check in form (one to many)
check in record form (check in, check in record one to many)

if you set up two queries
students sign in by student number and course number
teachers query by faculty number and course number

when I implemented this system, a number of tables were created for any query action, in order to get information about course scheduling, courses, teachers, and colleges.

I think it"s a little troublesome to do this. But to put it into the code implementation, you have to constantly initiate queries for many times. no, no, no.

for example, this is what I just wrote, a course that this student needs to sign in this week. I want to see what blind writing can look like. I have achieved the purpose of the function

        SELECT
        att.user_usr_id, att.course_coz_id,
        sch.sch_id, sch.sch_year, sch.sch_term, sch.sch_start_week, sch.sch_end_week,
        sch.sch_fortnight, sch.sch_day, sch.sch_start_time, sch.sch_end_time, sch.course_coz_id, sch.location_loc_id,
        loc.loc_id, loc.loc_name,
        coz.coz_id, coz.coz_name, coz.coz_size, coz.coz_act_size, coz.coz_att_rate,
        tea.user_usr_id tea_user_usr_id, tea.course_coz_id,
        tch.usr_name tea_user_usr_name,
        coz_sch.sch_id coz_sch_id, coz_sch.sch_year coz_sch_year, coz_sch.sch_term coz_sch_term,
        coz_sch.sch_start_week coz_sch_start_week, coz_sch.sch_end_week coz_sch_end_week, coz_sch.sch_fortnight
        coz_sch_fortnight,
        coz_sch.sch_day coz_sch_day, coz_sch.sch_start_time coz_sch_start_time, coz_sch.sch_end_time coz_sch_end_time,
        coz_sch.course_coz_id coz_sch_course_coz_id, coz_sch.location_loc_id,
        coz_sch_loc.loc_id coz_sch_loc_id, coz_sch_loc.loc_name coz_sch_loc_name,
        si_id, si_week, si_time, si_auto,
        sir_id, sir_time, sir_leave, sir_approve, sir_voucher, sir.sign_in_${curYear}_${curTerm}_si_id sir_id,
        sir.user_usr_id sir_user_usr_id
        FROM attendance att
        JOIN schedule sch ON att.course_coz_id = sch.course_coz_id
        LEFT OUTER JOIN location loc ON loc.loc_id = sch.location_loc_id
        <!-- sch coz -->
        JOIN course coz ON sch.course_coz_id = coz.coz_id
        LEFT OUTER JOIN teaching tea ON coz.coz_id = tea.course_coz_id
        LEFT OUTER JOIN schedule coz_sch ON coz.coz_id = coz_sch.course_coz_id
        LEFT OUTER JOIN location coz_sch_loc ON coz_sch.location_loc_id = coz_sch_loc.loc_id
        JOIN user tch ON tea.user_usr_id = tch.usr_id
        <!-- history sign in -->
        JOIN sign_in_${curYear}_${curTerm} si ON sch.sch_id = si.schedule_sch_id
        LEFT OUTER JOIN sign_in_rec_${curYear}_${curTerm} sir ON
        si.si_id = sir.sign_in_${curYear}_${curTerm}_si_id AND
        att.user_usr_id = sir.user_usr_id
        <where>
            sir.sir_id IS NULL <!-- de  -->
                AND att.user_usr_id = -sharp{usrId} <!-- id  -->
        </where>

you write back so many fields, it's hard to say that all of them are needed by the current user. You can consider two suggestions: one is to decompose the fields according to the specific query scenarios. Second, the view is established for some joint queries, and the conditional query is added to the view, so that the business logic is clearer and the permissions can be easily controlled at the same time. In addition, the fields with few changes are properly redundant and saved in multiple tables, which can improve the efficiency of the query.
personally believes that following the paradigm premise ensures query efficiency and development time, and the benefit is easy maintenance and reduced storage space (who cares? ). What needs to be done is to strike a balance between benefits and costs.


table association is recommended not to exceed 2 tables. You can use code for logical optimization.

Menu