鍍金池/ 問答/人工智能  Java  數(shù)據(jù)庫/ mysql和java多表join業(yè)務(wù)優(yōu)化?

mysql和java多表join業(yè)務(wù)優(yōu)化?

寫作業(yè)的思考。假如有這么一個簽到系統(tǒng)

按照范式設(shè)計有

學(xué)院表
課表(學(xué)院課表一對多)
老師表
學(xué)生表
教課表(老師課表多對多)
上課表(學(xué)生課表多對多)
排課表(課表排課一對多)
簽到表(排課簽到一對多)
簽到記錄表(簽到,簽到記錄一對多)

假如設(shè)定兩個查詢
學(xué)生由學(xué)號和課號查詢簽到
教師由教工號和課號查詢

而在我實現(xiàn)這個系統(tǒng)時,隨便一個查詢動作都建立了好多張表,為了獲取排課,課程,老師,學(xué)院信息。

我覺得這樣做,,有點麻煩?可是把它放到代碼實現(xiàn)也要不斷發(fā)起查詢很多次呀。。

比如這是我剛剛寫的,,一個獲取這個學(xué)生本周需要簽到的課程,我想看看瞎幾把寫可以聯(lián)立成什么樣子,。功能的目的我達(dá)到了

        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 = #{usrId} <!-- 用戶id  -->
        </where>
回答
編輯回答
她愚我

你回寫這么多字段,很難說都是當(dāng)前用戶需要的??梢钥紤]兩點建議, 一是可以根據(jù)具體查詢場景對字段分解下。二是對部分聯(lián)合查詢建立視圖,對視圖再加上條件查詢,業(yè)務(wù)邏輯更清晰,同時權(quán)限也好控制。還有就是對改動不多的字段進行適當(dāng)冗余,保存在多個表里,這樣可以提高查詢效率。
個人認(rèn)為遵守范式前提保證查詢效率和開發(fā)時間,得到的好處是便于維護和減少存儲空間(誰還在乎這個?)。需要做的就是好處和成本之間做均衡。

2017年4月9日 04:41
編輯回答
疚幼

表關(guān)聯(lián)建議不要超過2張表??梢杂么a進行邏輯優(yōu)化。

2018年8月6日 21:05