資料庫橫表

『壹』 資料庫縱表變橫表會不會影響性能

橫表就是普通的建表方式，如一個表結構為：主鍵、欄位1、欄位2、欄位3。。。 如果變成縱表後，則表結構為： 主鍵、欄位代碼、欄位值。而欄位代碼則為欄位1、欄位2、欄位3。 具體為電信行業的例子。以用戶帳單表為例一般出賬時用戶有很多費用客戶，其數據一般存儲為：時間，客戶ID,費用科目，費用。這種存儲結構一般稱為縱表，其特點是行數多，欄位少。縱表在使用時由於行數多，統計用戶數或對用戶進行分檔時還需要進行GROUP BY 操作，性能低，且操作不便，為提高性能，通常根據需要將縱表進行匯總，形成橫表，比如：時間、客戶ID,基本通話費、漫遊通話費，國內長途費、國際長途費....。通常形成一個客戶一行的表，這種表統計用戶數或做分檔統計時比較方便。另外，數據挖掘時用到的寬表一般也要求是橫表結構。縱表對從資料庫到內存的映射效率是有影響的，但細一點說也要一分為二：縱表的初始映射要慢一些；縱表的變更的映射可能要快一些，如果只是改變了單個欄位時，畢竟橫表欄位比縱表要多很多

『貳』 動態sql語句實現橫表轉豎表，成績轉成列

這個貌似不可以吧，
其實你沒有必要在資料庫裡面建這樣的欄位，只要在 你的空間上標明 [網路課] 就可以了

『叄』 關於電商網站資料庫的設計有什麼好的建議

這個問題的核心點在於：不同商品類別差異很大，如何設計通用的存儲方案？簡單來說，用資料庫去存儲所有信息，不管橫表還是縱表，都有明顯的缺陷：橫表：同一個欄位對不同商品含義不一樣，這到了後面開發和維護是很蛋疼的縱表：一個商品的屬性分布到很多行記錄中，業務處理很麻煩，而且縱表的記錄數會非常多，性能會有問題所以不要嘗試只用資料庫去統一解決這個問題，思路擴散一些其實就簡單了：公共表：提煉商品公共的信息放到資料庫，例如商品id、名稱、發布的商家、發布日期、上架狀態擴展表：將變化的信息放到另外一個表，可以是資料庫表，例如電腦商品一個表、服裝一個表；也可以將信息放到MongoDB或者ElasticSearch這類文檔資料庫。搜索組件：擴展表在全文搜索的時候不好實現，因此需要獨立的組件負責搜索，可以用Elastic Search或者Solr來冗餘一份數據，用於搜索。表結構不算復雜，因為項目關系只有SPU，沒有涉及到SKU，但是可以做參考，更多的還是要根據項目實際情況設計。重點說明一下產品表的SPU，Keyword欄位。本來之前設計了關系表，但是發現在做SQL查詢時太痛苦，所以約定了一種數據存儲結構（數據結構的重要性）基於上面的基礎，可以實現URL規則變化的查詢,類似京東的產品查詢URL變化c=1,3 指分類層次關系ev=3_1+4_18 指SPU查詢 按約定規則轉換成字元串再進行查詢。

『肆』 資料庫sql 問題

select年份,sum(casewhen季度=1then產量end),sum(casewhen季度=2then產量end),sum(casewhen季度=3then產量end),sum(casewhen季度=4then產量end)from表名groupby年份orderby年份