台灣最大程式設計社群網站
線上人數
869
 
會員總數:246713
討論主題:190131
歡迎您免費加入會員
討論區列表 >> MySQL >> 聯絡人資料庫結構設計
[]  
[我要回覆]
1
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
聯絡人資料庫結構設計
價值 : 48 QP  點閱數:2140 回應數:6
樓主

bon
門外漢
0 24
616 45
發送站內信

各位先進好

近來初學資料庫,目前在做聯絡人的資料結構,一個聯絡人可能有以下屬性:
1.中文姓名 (一個聯絡人只有一個)
2.英文姓名 (一個聯絡人只有一個)
3.聯絡人類型 (ex:教育界、小吃業、製造業...)
4.公司
5.部門
6.職稱/身分 (聯絡人可能同時有多個身分、公司,包含該聯絡人過去的身分)
7.專長 (可能有多個專長,ex:化工、C++、廣告美工...)
8.住址 (可能有多個住址,包含區號zip code)
9.電話 (可能有多個)
10.手機 (可能有多個)
11.傳真 (可能有多個)
12.信箱 (可能有多個)
13.個人網站 (可能有多個)
14.願意接受活動通知 (Y/N)
[hr]

資料庫結構圖請見以下網址:
(省略過)https://imageshack.com/i/plEoFn12j
(完全圖)https://imageshack.com/i/po84068Oj

1.聯絡人的數量定在10萬人。
2.市話、手機、傳真、信箱考慮整合成一個表格「聯絡方式」,用聯絡類型來表示號碼的類型。見圖中左下。
3.正規化:之前有學到資料庫正規化要避免一個欄位內有多筆資料,例如某聯絡人的身分為「X校X系主任, X校X系博士, XX教授, XX學會會長」,所以我把這些分成很多個表格。除了英文姓名是唯一的,其它表格內一個聯絡人可能有0個以上的資料。但是表格的PK又因為必須是唯一卻沒有使用價值,是否這個case並不做正規化比較好?
4.重複字串索引:因為人數在10萬以上,某些重複頻率高的字串如聯絡人類型,將字串另外存在一個表格。

請各位先進不吝指教,我的概念是否正確,任何建議與指正都非常歡迎,謝謝!

搜尋相關Tags的文章: [ Database Structure ] , [ 資料庫結構 ] ,
本篇文章發表於2016-02-02 11:26
1樓
作者回應

bon
檢舉此回應
之後需要製作用戶端使用介面,用來進行聯絡人查詢與修改。最多約20人在線,如何保證每個人看到的資料是最新的,也是我目前在思考的問題。
本篇文章回覆於2016-02-02 11:34
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
2樓
作者回應

bon
檢舉此回應
各位好,昨天我想過之後改變了一些地方。請至以下網址查看資料庫架構:
https://imageshack.com/i/poZLl0Hij

1.我覺得上一個版本或許正規化過頭了,之後的查詢效率會因此降低。反正到時候用SQL語法撈出來後,我會再用C#去做多種檢視模式,所以我將聯絡人身分、電話、手機、電子郵件、住址、專長這些欄位放進Table_聯絡人,這些欄位通常會有至少一個Value,超過一個時用逗號分隔。而個人網站、傳真、英文姓名這些欄位相對較少使用,所以另外建立Table以節省Table_聯絡人的空間。
2.Table_住址內含區號(ex:943)與地址(ex:獅子鄉竹坑巷60號)。每個區會包含在一個縣市內。Table_縣市的屬性地區為「北部、中部、南部、東部、離島」。這樣分的原因是為了之後可以針對特定縣市或地區做查詢。
3.公司網站紀錄在Table_公司,與Table_個人網站作區別。
本篇文章回覆於2016-02-03 10:21
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
3樓
最有價值解答

浩瀚星空
捐贈 VP 給 浩瀚星空 檢舉此回應
感覺上在規劃上還是覺得有點複雜。

基本上我依照你上面的情況。我會先決定好一些表。
將唯一性的表及複合性的表分開

依照你圖中的資料,我大約理解的情況如下

公司 -> 部門 職稱 這是唯一性

聯絡人表 這是複合性資料。

而聯絡人中又有其複合性資料如「專長、聯絡項目(電話、email等等)」

所以依照上面的特性。我資料表會大致上規劃如下。

公司表office:公司id(oid)、公司名稱、統編、聯絡資料。(基本上公司的聯絡資料我不會做成複合性,會直接就放到公司表內)
部門表:部門id(gid)、公司id(oid)對應公司用、部門名稱......
職稱表:職稱id、職稱名稱、部門id、公司id

職稱表的部份由於不太了解你的特性。一般如果是要分各公司及部門的情況。確實是要保留部門id跟公司id。
只是這樣的設計有時會佔用太多重覆的資料。一般如果同性質的公司居多的話。
我可能不會再用公司id跟部門id做區分。
優點是資料不用太多,缺點就是在建立聯絡人會有許多不相關的職稱出現。
不過在規劃上,其實我不會將職稱額外做表出來。而是會直接單純文字寫入到聯絡人表上。


再來就是聯絡資料的部份
聯絡人表:聯絡人id、公司id、部門id、職稱id或是名稱
聯絡項目1(也可以做額外項目):uid(索引可重覆)、電話、手機、住址、email.....(加其它資料)

聯絡項目的部份也可以用另外一種設計。
聯絡項目2:uid、項目分類(就是這個值是手機、電話、住址或是email)、項目值

第一種聯絡項目的好處是單純對應比較方便,缺點就是可能會產生許多空項目資料出來
第二種就比較不容易佔用空間。但缺點就是在撈資料時,還得利用一下程式整合出來並輸出。
不過我會比較偏向第二種方式就是了。因為用第二種就可以將專長也一起放在此了。
本篇文章回覆於2016-02-15 15:47
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
4樓
作者回應

bon
檢舉此回應
感謝浩瀚星空大大回覆

https://imageshack.com/i/plc8kyCfj

我也覺得聯絡方式用第二種比較好,不過專長有可能經常由使用者新增或變更,所以我還是將所有專長列在一個表,之後程式比較簡單存取。其餘的部分就歸到通訊那邊。

因為我之前是希望能夠紀錄一個聯絡人的經歷,連他過去待過哪些公司也記錄下來,打算做聯絡人之間的關聯,並且更充分地認識這個聯絡人,實現精準行銷!! ...之類的。
不過現階段還是先不考慮這個了,所以改成唯一的簡單點,經歷以後再用別的方式來儲存。

另外增加了銷售紀錄、標籤與聯絡紀錄。
標籤是讓使用者自由添加,算是自定義屬性在聯絡人身上。

聯絡紀錄的部分,我想讓使用者在每一次接觸客戶後,能夠在這裡摘要聯絡的事發經過。一來同事之間可以從這裡分享聯絡內容,再之後想從這裡去做後面的統計分析,例如客戶互動熱絡程度、業務鬼扯了什麼讓客戶掏錢、哪些地區比較少去發展業務等等。
但是,一個聯絡人的聯絡次數從幾次到數百次都有可能,那麼當初預設的十萬人恐怕會使這個表格有數百萬筆資料,當聯絡人越多這個表格的資料筆數就越多,這個表格將會是資料庫裡最大的。我還要再想想要怎麼修改。

本篇文章回覆於2016-02-15 23:22
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
5樓
回應

浩瀚星空
捐贈 VP 給 浩瀚星空 檢舉此回應
其實倒是不用太擔心這個問題。如果你的索引有建立好的話。
幾百萬也不是問題的。(就是佔用的容量會多點就是了)

只要不是一撈就是幾百萬筆。
一般來說如果從幾百萬筆中撈出10筆。並不會去影響其效能的。

如真擔心。也可以做成分表處理。

我說的第二種方式就是屬性自定義屬性的模式。
當然如何區分也是看你。你可以將自定義全放在一張表上。這樣的確會有你所說的資料筆數過多的問題。
但程式會比較容易處理。

也可以后分一些大分類。如通訊資料、專長、經歷切分三個表。
但這樣子或是不會有大資料表的產生。但在程式上也一定得要取三次表。
視情況並不一定也是好處。

所以得要先了解你的模式跟型態來決定要放一張表還是要拆表。
本篇文章回覆於2016-02-16 16:36
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
6樓
作者回應

bon
檢舉此回應
感謝您的協助,架構修改之後比較有信心做出來了。
本篇文章回覆於2016-02-16 22:38
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
   
1

回覆
如要回應,請先登入.