2019/0418/SQL指標、索引&Use cace

SQL資料指標

靈活一點的操作

利用指標物件stuCursor的移動去讀取資料

只有指標指到的資料可以增刪修 就像sqldataread(但這個只能往下走)

可以節省記憶體

靜態指標

Select結果存為物件轉為靜態指標

Open stucursor 使用完要

close stucursor deallocate stucursor 歸還記憶體

Fetch first 第一筆 into 在哪個欄位

每移動系統變數就會有個值

@@FETCH_STATUS

有值就是有資料 0

為沒資料 -1 代表找完了 (讀完) 

--資料指標Cursor
--宣告靜態資料指標
declare stuCursor cursor
static --靜態指標
for select 學號,姓名,電話 from 學生
open stuCursor
	declare @id char(4), @name varchar(12), @tel varchar(15)
	fetch first from stuCursor into @id,@name,@tel
	while @@FETCH_STATUS=0
	begin
		print 'id='+@id+',name='+@name+',tel='+@tel
		fetch next from stuCursor into @id,@name,@tel
	end

close stuCursor
deallocate stuCursor
go

Key指標 、

diynamic 動態資料指標 ( key也不存了 ( 就像 sqldatareader

如果有人對表增刪修會不同步

那就是當前資料遺失

資料遺失 -2

嚴謹一點判斷資料遺失

因為是while迴圈只要不是-1 

declare stuCursor cursor
keyset --key指標
for select 學號,姓名,電話 from 學生
open stuCursor
	declare @id char(4), @name varchar(12), @tel varchar(15)
	fetch first from stuCursor into @id,@name,@tel
	while @@FETCH_STATUS<>-1
	begin
		if @@FETCH_STATUS=-2
			print '當前資料遺失'
		else
			print 'id='+@id+',name='+@name+',tel='+@tel
		
		fetch next from stuCursor into @id,@name,@tel
	end

close stuCursor
deallocate stuCursor

題外話: 資料庫實務上很少寫到delete通常是駭客

資料指標的移動

好處:如果沒有寫資料表關聯怎麼指標就會出什麼

相對/絕對位置。往前為正往前後為負

系統變數計算指標裡面有幾列

@@CURSOR_ROWS

( 可以是計算 WHERE或 JOIN …

迴圈裡面不能寫 absolute 不然會無窮迴圈 

--fetch first 指標移至第一筆資料
--fetch next 指標移至下一筆資料
--fetch prior 指標移至上一筆資料
--fetch last 指標移至最後一筆資料

--fetch absolute 3 --移動到第三筆資料
--fetch relative 3 --移動到目前指標位置的後面三筆資料
--fetch relative -3 --移動到目前指標位置的前面三筆資料
----------------------------
declare staff_cursor cursor
static
for select 身份證字號,姓名 from 員工
open staff_cursor
declare @id char(10), @name varchar(12)
if @@CURSOR_ROWS>0
begin
	fetch first from staff_cursor into @id,@name
	while @@FETCH_STATUS=0
	begin
		print @name
		fetch relative 2 from staff_cursor into @id,@name
	end
end
close staff_cursor
deallocate staff_cursor
go
------------------------------------------------------
declare staff_cursor cursor
static
for select 身份證字號,姓名 from 員工
open staff_cursor
declare @id char(10), @name varchar(12), @inc int
if @@CURSOR_ROWS>0
begin
set @inc=@@CURSOR_ROWS/3
	fetch first from staff_cursor into @id,@name
	while @@FETCH_STATUS=0
	begin
		print @name
		fetch relative @inc from staff_cursor into @id,@name
	end
end
close staff_cursor
deallocate staff_cursor
go

題外話: 台積電 oem odm 轉型有成功研發能量非常強

連電直接gg

資料更改頻繁時(更新與刪除)

資料為了確保資料正確性

就有交易處理機制並行控制

直接修改指標所指的地方

--更新與刪除
--牽涉到並行控制問題
-------------------------------
declare staff_cursor cursor
keyset
for select 身份證字號,姓名,薪水 from 員工
open staff_cursor
declare @id char(10), @name varchar(12), @salary money
if @@CURSOR_ROWS>0
begin
	fetch first from staff_cursor into @id,@name,@salary
	while @@FETCH_STATUS=0
	begin
		print '目前的薪水'+cast(@salary as varchar)
		set @salary*=1.03
		update 員工 set 薪水=@salary where current of staff_cursor
		fetch next from staff_cursor into @id,@name,@salary
	end
end
close staff_cursor
deallocate staff_cursor

資料表索引概念

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

Previous2019/0417/伺服器網域ADDNS&416LINE討論Next2019/0419/主頁、Webform ADO.NET Entity Fromwork 增刪修實作&第五次專題報告

Last updated