2019/0418/SQL指標、索引&Use cace
SQL資料指標
靈活一點的操作
利用指標物件stuCursor的移動去讀取資料
只有指標指到的資料可以增刪修 就像sqldataread(但這個只能往下走)
可以節省記憶體
靜態指標
Select結果存為物件轉為靜態指標
Open stucursor 使用完要
close stucursor deallocate stucursor 歸還記憶體
Fetch first 第一筆 into 在哪個欄位
每移動系統變數就會有個值
@@FETCH_STATUS
有值就是有資料 0
為沒資料 -1 代表找完了 (讀完)
Key指標 、
diynamic 動態資料指標 ( key也不存了 ( 就像 sqldatareader
如果有人對表增刪修會不同步
那就是當前資料遺失
資料遺失 -2
嚴謹一點判斷資料遺失
因為是while迴圈只要不是-1
題外話: 資料庫實務上很少寫到delete通常是駭客
資料指標的移動
好處:如果沒有寫資料表關聯怎麼指標就會出什麼
相對/絕對位置。往前為正往前後為負
系統變數計算指標裡面有幾列
@@CURSOR_ROWS
( 可以是計算 WHERE或 JOIN …
迴圈裡面不能寫 absolute 不然會無窮迴圈
題外話: 台積電 oem odm 轉型有成功研發能量非常強
連電直接gg
資料更改頻繁時(更新與刪除)
資料為了確保資料正確性
就有交易處理機制並行控制
直接修改指標所指的地方
資料表索引概念
ACCESS 講過 每個欄位一定都有索引 有三個選項
否
是可重複
是不可重複
可以讓注音當索引可以讓部首當索引等等…
不然沒有索引只能地毯式搜索掃描
縮小搜尋範圍可以提升搜尋速度 ( 至少要百萬筆以上才會感受到
資料表裡面一定要有一個索引 ( 實務上可能會沒有要去check
常常至於 where 後面 就適合作為索引 p.k. index
Sool叢集索引
max 索引 128
題外話: 鴻海四月到現在 漲了 50% 100萬變200萬 但現在正乖離太大
資訊公開揭露站http://mops.twse.com.tw/mops/web/index
郭台銘 自己偷買
切回正題
回到sqlserver
主鍵 pk 一定是 索引index
叢集索引可以直接對資料data
非叢集索引會限制範圍後掃pk掃叢集才找的到資料
Pk盡量 長度固定 能短不長
Char 快
Varchr 慢
為何不所有欄位都建立索引?
索引會在索引表要資料庫去維護,越多索引維護成本越高。
索引不建立速度會差2-30倍
遞移相依被第三正規化的 fk 都要被建立成索引
什麼樣的欄位不能重複資料呢?除了pk
Unik 候選鍵 交替鍵 ( 好處 ? 速度快 但還是要非叢集跑到叢集
每一個欄位都可被建立索引
但有兩種欄位不適合當索引
值重複太多,值字數太多
實務上
要盡量建立索引的資料表,
在寫sql的時候基本上先求有再求好,
再靠軟體壓力測試做調整。
Table array 實際上是 B tree
##資料結構 要取補起來 7維 8維 ???
陣列 是一維其實空間佔據很大 但效率很好
Link – list 節省空間 但沒有索引
只能犧牲時間複雜度或是犧牲空間複雜度
依照機器 (電腦 或是 小裝置 洗衣機 冰箱?
Tree 省空間 又效能好 中間值 ( 種類也蠻多的2-30種 big tree 效能很好
樹要提升效率 會有演算法提升效率
最快的方式是二分搜尋法
( 切半 ( 限制資料要排序過 ( 最多幾次會找到 至少幾次會找到
以上都跟數學有關係 純數 ? 資料庫底層是一套數學模型
##下午題外話
靈堂布置、線上拜拜、宗教選擇
= = 我們老師突然在談 寵物追思網站
可是布置道具 屬於 線上金幣或儲值這樣
感覺這樣毛利很低要靠寵物口紅利
還是倒了 看來還是要像龍巖那樣才有得賺
線上大概這樣
實際一堆款項能賺
14:20 ㄩ\ㄔㄥ/ 應該頂多 從我現在這個專案下手
14:20 ㄩ\ㄔㄥ/ 寵物交友
14:20 ㄩ\ㄔㄥ/ 裡面有可以記錄寵物相關的 之類的 然後也是搞個 線上寵物園地之類的
14:20 ㄩ\ㄔㄥ/ 等會員對這平台有依賴
14:20 ㄩ\ㄔㄥ/ 在從 寵物 生 -> 死
14:21 ㄩ\ㄔㄥ/ 但是只做 代銷
14:21 ㄩ\ㄔㄥ/ 生的就搞 醫療跟食物跟穿著 等等 玩具之類
14:21 ㄩ\ㄔㄥ/ 死的就搞 每年的祭祀 死掉的後續 念經骨灰塔位 樹葬 盆葬 海葬 啥的 跟人一樣
14:22 ㄩ\ㄔㄥ/ 骨灰做成項鍊之類 然後賣超貴
從生到死 讓會員對這平台黏濁度高一點
14:39 ㄩ\ㄔㄥ/ 你看這個寵拍 app
14:39 ㄩ\ㄔㄥ/ 2016的時候曾經 有50萬的使用人口
14:40 ㄩ\ㄔㄥ/ 結果 他們經營群好像自己投資別的搞砸了
14:40 ㄩ\ㄔㄥ/ 整個直接消失下架
https://twitter.com/mobiusbobs
溜寵物地圖
回正題 下午 各組題問
usecase
會員 會員訂購usecase
選購商品 放進購物車 結帳 貨到付款 匯款 輸入折扣碼
一定要有的往被用的話a用到b,b->a
第一個找使用者
第二個找行為
第三個找關聯
退貨就要另外一個 usecase
Include : a case 一定會用到 b case
Extend : a case 有時候會用到 b case
Gernelazation : a case 與 b case 有繼承
需求分析文件用的給程式設計師看得
看不懂那個usecase時要去下一層看
是一種階層關係
Usecase 不表現流程 循序圖與活動圖才會表現
階層點
1.0
1.1.1.1.1 …
隨系統分析師決定要畫的完整性
做系統分析文件的底稿
設計規格才會有很細節的描述
功能會寫在規格裡面
Usecase 跟 erd 沒有衝突
系統分析兩種做法
物件導向 usecase
結構化 環境圖 流程圖
文件化
系統分析 反覆精煉 在軟體開發生命週期大概佔60% 板根 維護 產品要賣
如果是接case單一賣家 就比較不會重視以上
CMMI – level3
426各組報告大功能的usecase
Last updated