作者derekhsu (華麗的天下無雙)
看板Soft_Job
標題Re: [請益] 是我經驗不足嗎?關於資料設計認知差異
時間Thu Oct 2 00:07:24 2008
※ 引述《valenamuro (徵軟體工程師唷)》之銘言：
: 今天與主管討論資料庫欄位設計時，對於資料庫欄位設計有一些地方無法共識
: 一般我們設計資料庫欄位設計都是屬於橫向方式作設計，如下所示:
: 第一筆資料 欄位A 欄位B ..........
: 第二筆資料 欄位A 欄位B ..........
: .............
: 第N筆資料
: 但是，主管說為了日後彈性而言，要改由縱向設計，設計方式如下:
: 第一筆資料 第二筆資料 ...............第N筆資料
: 欄位A 欄位A........................欄位A
: 欄位B 欄位B........................欄位B
: ..... ..... ......
: 這樣就在日後要每筆資料有需要新增資訊，就不需要再改資料庫欄位
: 想請問一下，具我所知，一般大都採用橫向比較多，有人會採用縱向方式設計嗎?
: 這樣設計不是效能很不好??
: 業界跟理論有這樣大誤差 =.=..
我知道這個故事，我還以為那位主管已經不在了，想不到那位主管還在啊
不知道是不是同一個主管。某家已經倒掉的公司的....XD
我覺得你是對你的主管的結構有點誤會，可能是這樣子的，
話說回來這種結構不是沒有作用，在某些狀況之下，比如資料的欄位不固定
但是資料量卻不多，與其他資料表之間的關聯也不密切的狀況下，這樣的做
法的確可以增加彈性。我也有拿來用在描述產品規格上面，簡單來說，就是
做Metadata的描述，這樣做是可以被接受的。
舉例來說，我現在有五個產品，這五個產品的規格不太一樣，比如
第一個產品：
長度 10
重量 3
期限 1
第二個產品
長度 5
重量 2
價值 10
第三個產品
圓周 7
密度 5
第四個產品
...
第五個產品
...
然後你還會有第六個，第七個產品，而且這些產品的描述子都不固定的時候
，就可以用這個方法，比如：
編號 規格 數值
1 長度 10
1 重量 3
1 期限 1
2 價值 10
....
以此類推，在資料量不多的狀況下，確實比用
編號 長度 重量 期限 價值 圓周
1 10 3 1 null null
....
的要有彈性
但是這是在少數的狀況下才有辦法運作的動作，當你要進行增加的時候，你
就會發現要哭了，橫向的資料表效能極差，你要插入一筆資料，等於要做
n個資料庫的Insert操作，原本只是一個操作而已，當然Update跟Delete也
全部一樣，join運算的時候更是會慢到哭出來。
當你提出效能上得問題的時，假設主管回你多建幾個索引就可以了，我建議
你把桌上的文件拿起來丟到他臉上，然後罵他「吃大便吧」
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.166.211.47
※ 編輯: derekhsu 來自: 118.166.211.47 (10/02 00:14)
1F：推 andymai:沒想到這樣的主管還有人遇到~不過最後那段大概要很有guts 10/02 00:19
2F：→ andymai:然後又不想在業界呆了~才會這樣做吧... 10/02 00:19
3F：推 iman00b:這跟要不要在業界呆有啥關係？何必尊重連基本學能都沒的人 10/02 04:23
4F：→ iman00b:連我在搞firmware的都懂一點資料庫了，這還不夠基本？ 10/02 04:24
5F：推 ledia:轉換跑道, reference check 被踩一腳, 就知道以和為貴的重要 10/02 11:31
6F：推 andymai:正如樓上所言~搞不好那個主管的人脈廣闊~人言可畏啊!如果 10/02 20:40
7F：→ andymai:有老闆聽聞了~試問哪個老闆不會對這個人的人格特質打問號? 10/02 20:42
8F：→ andymai:不對盤的話~閃人就好了~跟他吵有意義嗎? 10/02 20:44
9F：推 jellyice:基本學能跟尊不尊重沒關係…能力高並不代表就值得尊重 10/04 01:22
10F：→ michaelz:借轉database版 謝謝 10/04 07:17
11F：推 f1234518456:他要的方式就開spec簽名 出事就他扛就好 顆顆 09/01 11:38