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

SQL資料指標

靈活一點的操作

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

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

可以節省記憶體

### 靜態指標&#xD;

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

Open stucursor 使用完要&#x20;

close stucursor deallocate stucursor 歸還記憶體

Fetch first 第一筆 into 在哪個欄位

每移動系統變數就會有個值&#x20;

@@FETCH\_STATUS&#x20;

有值就是有資料 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指標 、 &#xD;

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

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

那就是當前資料遺失

資料遺失 -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通常是駭客

### 資料指標的移動&#xD;

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

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

系統變數計算指標裡面有幾列&#x20;

@@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

### 資料更改頻繁時(更新與刪除)&#xD;

資料為了確保資料正確性

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

直接修改指標所指的地方

```
--更新與刪除
--牽涉到並行控制問題
-------------------------------
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
```

### 資料表索引概念&#xD;

ACCESS 講過 每個欄位一定都有索引 有三個選項&#x20;

否

是可重複

是不可重複

可以讓注音當索引可以讓部首當索引等等…

不然沒有索引只能地毯式搜索掃描

縮小搜尋範圍可以提升搜尋速度 ( 至少要百萬筆以上才會感受到

![](/files/-LdDgP7__HK-k4eJJlvk)

![](/files/-LdDgVlPSooGuwTynFIz)

資料表裡面一定要有一個索引 ( 實務上可能會沒有要去check

常常至於 where 後面 就適合作為索引 p.k. index

Sool叢集索引

max 索引 128

題外話: 鴻海四月到現在 漲了 50% 100萬變200萬 但現在正乖離太大

資訊公開揭露站<http://mops.twse.com.tw/mops/web/index>

郭台銘 自己偷買

### 切回正題&#xD;

![](/files/-LckT5GK_z2zL8yWtFYe)

回到sqlserver

主鍵 pk 一定是 索引index

叢集索引可以直接對資料data

非叢集索引會限制範圍後掃pk掃叢集才找的到資料

Pk盡量 長度固定 能短不長

Char 快

Varchr 慢

為何不所有欄位都建立索引?&#x20;

索引會在索引表要資料庫去維護，越多索引維護成本越高。

索引不建立速度會差2-30倍

遞移相依被第三正規化的 fk 都要被建立成索引

![](/files/-LckT8dBjweBdWkkpz7D)

![](/files/-LdDgg5vSH7s8omlRbPu)

什麼樣的欄位不能重複資料呢?除了pk

Unik 候選鍵 交替鍵 ( 好處 ? 速度快 但還是要非叢集跑到叢集

每一個欄位都可被建立索引

但有兩種欄位不適合當索引

值重複太多，值字數太多

### 實務上 &#xD;

要盡量建立索引的資料表，

在寫sql的時候基本上先求有再求好，

再靠軟體壓力測試做調整。

Table array 實際上是 B tree

\##資料結構 要取補起來 7維 8維 ???

陣列 是一維其實空間佔據很大 但效率很好

Link – list 節省空間 但沒有索引

只能犧牲時間複雜度或是犧牲空間複雜度

依照機器 (電腦 或是 小裝置 洗衣機 冰箱?

Tree 省空間 又效能好 中間值 ( 種類也蠻多的2-30種 big tree 效能很好

樹要提升效率 會有演算法提升效率&#x20;

最快的方式是二分搜尋法&#x20;

( 切半 ( 限制資料要排序過 ( 最多幾次會找到 至少幾次會找到

以上都跟數學有關係 純數 ? 資料庫底層是一套數學模型

{% embed url="<https://zh.wikipedia.org/wiki/B%E6%A0%91>" %}

{% embed url="<https://mp.weixin.qq.com/s/cK_GIhCuGoUwJpDpoaETxw>" %}

{% embed url="<https://mp.weixin.qq.com/s?__biz=MzI1MTIzMzI2MA==&mid=2650561220&idx=1&sn=2a6d8a0290f967027b1d54456f586405&chksm=f1feec47c689655113fa65f7911a1f59bbd994030ad685152b30e53d643049f969eefaa13058&scene=21#wechat_redirect>" %}

\##下午題外話

靈堂布置、線上拜拜、宗教選擇

\= = 我們老師突然在談 寵物追思網站

可是布置道具 屬於 線上金幣或儲值這樣

感覺這樣毛利很低要靠寵物口紅利

{% embed url="<https://www.ntpc.gov.tw/ch/home.jsp?id=28&parentpath=0,6,27&mcustomize=multimessages_view.jsp&dataserno=201603280014>" %}

{% embed url="<https://pet.talk.tw/Article.aspx?ClassID=3&Article_ID=493>" %}

還是倒了 看來還是要像龍巖那樣才有得賺

線上大概這樣

實際一堆款項能賺

14:20 ㄩ\ㄔㄥ/ 應該頂多 從我現在這個專案下手

14:20 ㄩ\ㄔㄥ/ 寵物交友

14:20 ㄩ\ㄔㄥ/ 裡面有可以記錄寵物相關的 之類的 然後也是搞個 線上寵物園地之類的

14:20 ㄩ\ㄔㄥ/ 等會員對這平台有依賴

14:20 ㄩ\ㄔㄥ/ 在從 寵物 生 -> 死

14:21 ㄩ\ㄔㄥ/ 但是只做 代銷

14:21 ㄩ\ㄔㄥ/ 生的就搞 醫療跟食物跟穿著 等等 玩具之類

14:21 ㄩ\ㄔㄥ/ 死的就搞 每年的祭祀 死掉的後續 念經骨灰塔位 樹葬 盆葬 海葬 啥的 跟人一樣

14:22 ㄩ\ㄔㄥ/ 骨灰做成項鍊之類 然後賣超貴

從生到死 讓會員對這平台黏濁度高一點

{% embed url="<https://www.google.com/search?q=%E5%AF%B5%E6%8B%8D+Pamily&oq=%E5%AF%B5%E6%8B%8D+Pamily&aqs=chrome..69i57j69i61l3&sourceid=chrome&ie=UTF-8>" %}

14:39 ㄩ\ㄔㄥ/ 你看這個寵拍 app

14:39 ㄩ\ㄔㄥ/ 2016的時候曾經 有50萬的使用人口

14:40 ㄩ\ㄔㄥ/ 結果 他們經營群好像自己投資別的搞砸了

14:40 ㄩ\ㄔㄥ/ 整個直接消失下架

{% embed url="<https://meet.bnext.com.tw/articles/view/38766>" %}

{% embed url="<https://www.facebook.com/PamilyApp/>" %}

{% embed url="<https://buzzorange.com/techorange/2016/08/13/pamily/>" %}

<https://twitter.com/mobiusbobs>

{% embed url="<https://buzzorange.com/techorange/2016/10/11/pamily-interview/>" %}

溜寵物地圖

回正題 下午 各組題問&#x20;

### usecase&#xD;

會員 會員訂購usecase&#x20;

選購商品 放進購物車 結帳 貨到付款 匯款 輸入折扣碼&#x20;

![](/files/-LckTfBu4i8OERARjb08)

一定要有的往被用的話a用到b，b->a

第一個找使用者

第二個找行為

第三個找關聯

退貨就要另外一個 usecase

Include : a case 一定會用到 b case

Extend : a case 有時候會用到 b case

Gernelazation : a case 與 b case 有繼承

需求分析文件用的給程式設計師看得

![](/files/-LckTiKXU_zV2gngQZQs)

看不懂那個usecase時要去下一層看

是一種階層關係

Usecase 不表現流程 循序圖與活動圖才會表現

階層點&#x20;

1.0

1.1.1.1.1 …&#x20;

隨系統分析師決定要畫的完整性&#x20;

做系統分析文件的底稿

設計規格才會有很細節的描述

功能會寫在規格裡面

Usecase 跟 erd 沒有衝突

系統分析兩種做法

物件導向 usecase

結構化 環境圖 流程圖

文件化

系統分析 反覆精煉 在軟體開發生命週期大概佔60% 板根 維護 產品要賣

如果是接case單一賣家 就比較不會重視以上

CMMI – level3

{% embed url="<https://www.google.com/search?q=CMMI&rlz=1C1GCEU_zh-TWTW835TW836&oq=CMMI&aqs=chrome..69i57j0l5.637j0j7&sourceid=chrome&ie=UTF-8>" %}

### 426各組報告大功能的usecase&#xD;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://johch3n611u.gitbook.io/c50108/ju-li-cheng-bei/201904/20190418sql-zhi-suo-yin-usecace.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
