Re: [請益] 是我經驗不足嗎?關於資料設計認知差異
※ 引述《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)
推
10/02 00:19, , 1F
10/02 00:19, 1F
→
10/02 00:19, , 2F
10/02 00:19, 2F
推
10/02 04:23, , 3F
10/02 04:23, 3F
→
10/02 04:24, , 4F
10/02 04:24, 4F
推
10/02 11:31, , 5F
10/02 11:31, 5F
推
10/02 20:40, , 6F
10/02 20:40, 6F
→
10/02 20:42, , 7F
10/02 20:42, 7F
→
10/02 20:44, , 8F
10/02 20:44, 8F
推
10/04 01:22, , 9F
10/04 01:22, 9F
→
10/04 07:17, , 10F
10/04 07:17, 10F
推
09/01 11:38, , 11F
09/01 11:38, 11F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 3 之 3 篇)：