Re: [請益] 是我經驗不足嗎?關於資料設計認知差異

[derekhsu (華麗的天下無雙)]

※ 引述《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)
推 andymai:沒想到這樣的主管還有人遇到~不過最後那段大概要很有guts
→ andymai:然後又不想在業界呆了~才會這樣做吧...
推 iman00b:這跟要不要在業界呆有啥關係？何必尊重連基本學能都沒的人
→ iman00b:連我在搞firmware的都懂一點資料庫了，這還不夠基本？
推 ledia:轉換跑道, reference check 被踩一腳, 就知道以和為貴的重要
推 andymai:正如樓上所言~搞不好那個主管的人脈廣闊~人言可畏啊!如果
→ andymai:有老闆聽聞了~試問哪個老闆不會對這個人的人格特質打問號?
→ andymai:不對盤的話~閃人就好了~跟他吵有意義嗎?
推 jellyice:基本學能跟尊不尊重沒關係…能力高並不代表就值得尊重
→ michaelz:借轉database版 謝謝
推 f1234518456:他要的方式就開spec簽名 出事就他扛就好 顆顆