2016-10-07 18 views
0

我正在開發一個項目,人們可以收到關於足球比賽(航班,酒店,景點,體育場)的信息。這個網站還應該包含一個預約清單(我的航班何時何地,我的旅館在哪裏,我什麼時候需要去球場......)我認爲這很酷,如果你參考航班,酒店等在這一任命表向用戶呈現一些額外的信息關於這一任命MySQL:在一個表中引用各種表ID

總的來說,我可以做s.th像

appointmentID | appointmentDate | appointmentDuration | flightID | hotelID | stadiumID 

,並填補了非必要的值與NULL。但我認爲這不是一個好主意。我

還可以保存他們這樣說:

appointmentID | appointmentDate | appointmentDuration | appointmentType | appointmentTypeID 

,並與表的字符串(酒店,機票,......),並與appointmentType的ID appointmentTypeID填寫appointmentType。但那樣感覺不好。

所以我的問題是:什麼是將這個值保存在數據庫中的最佳方式?

編輯:我知道目標是規範化表。一般來說,我知道我需要將哪些數據放在單獨的表格中。我的問題是如何在這種情況下做到這一點

+0

歸一化。越多的行越好 – Drew

+0

我知道默認答案是「規範化它」。問題是如何,因爲我沒有太多的數據可以從約會中提取。創建額外的表爲約會_飛行,約會_酒店預約ID和otherID在看起來不是一個好主意 – mirko911

+0

最好把一張桌子作爲一個對象在OOP而不是一個大雜燴的信息,可以是(A)不完整,( B)不適用,(C)不可擴展或靈活。我想給你打個電話,但我要去洋基隊和大都會隊。哦,我有兩個酒店大塊。我想你應該已經明白了。一般來說,考慮到水平與垂直的選擇,選擇垂直。 – Drew

回答

0

第一種方式似乎是一個更好的選擇。

我有以下的,但我想補充一個參考表

Appointment_table APP_ID app_f_id(引用飛行表的id) app_h_id(引用酒店表的id) app_s_id(引用的id體育場表) app_ref_table(這將包含一個唯一產生的參考,因爲利用該ID將成爲未來作爲ID可以延伸到數以百萬計問題...)

Flight_table F_ID f_carrier f_date_booking f_date_confirmed

Hotel_table h_id h_descripion h_guests

Stadium_table 每年S_ID s_description

參考表將與序列1或任何你喜歡開始。在我看來,這是桌子結構的整潔方法。 Reference_table R_ID r_year r_sequence r_app_id(最後的ID有產生的參考號碼)