查找表中不重複的列
select distinct 列 from 表複製代碼
SQL中所遇到的語句程序員
總體都是數據庫
SELECT COLUMN FROM TABLE編程
明確索要查詢獲得的結果緩存
Column=各類條件,不一樣值類型轉換,截取,判斷安全
SQL中幾個主要的知識點bash
- 遊標(不會)
- 索引(不會)
- 約束(知道)
- 視圖(不會)
- 事務處理(不會)
- 存儲過程(會一點,能看不會寫)
- 數據庫安全(不會)
6.什麼是存儲過程?有哪些優缺點?
數據庫中的數據等因而「水」服務器
Selecte語句是「吸管」網絡
那麼存儲過程就是「抽水管道」架構
存儲過程的優勢:
編程語言
- 存儲過程就像咱們編程語言中的函數同樣,封裝了咱們的代碼。(作好的管子用來取水,比較有針對性。篩出多餘和無效的數據)
- 可以將代碼封裝起來(屢次調用,不用重複寫)
- 保存在數據庫之中(同數據庫一塊兒,方便查詢修改)
- 讓編程語言進行調用(在不一樣的場景中能夠被使用,例如winfrom和網站)
- 存儲過程是一個預編譯的代碼塊,執行效率比較高(總體性,效率高)
- 一個存儲過程替代大量T_SQL語句 ,能夠下降網絡通訊量,提升通訊速率(同上)
存儲過程的缺點:
- 每一個數據庫的存儲過程語法由於不通用,十分難以維護
- 業務邏輯放在數據庫上,難以迭代
4.什麼是視圖?以及視圖的使用場景有哪些?
什麼是視圖?
視圖是一種基於數據表的一種虛表(能夠參考數據庫中的臨時表)
- (1)視圖是一種虛表
- (2)視圖創建在已有表的基礎上, 視圖賴以創建的這些表稱爲基表
- (3)向視圖提供數據內容的語句爲 SELECT 語句,能夠將視圖理解爲存儲起來的 SELECT 語句
- (4)視圖向用戶提供基表數據的另外一種表現形式
- (5)視圖沒有存儲真正的數據,真正的數據仍是存儲在基表中
- (6)程序員雖然操做的是視圖,但最終視圖還會轉成操做基表
- (7)一個基表能夠有0個或多個視圖
有的時候,咱們可能只關係一張數據表中的某些字段,而另外的一些人只關係同一張數據表的某些字段...
咱們應該作到:
他們想要看什麼數據,咱們就給他們什麼數據
一方面就可以讓他們只關注本身的數據
另外一方面,確保一些保密的數據不會泄露出來
視圖就是基於查詢的一種虛表,也就是說,視圖能夠將查詢出來的數據進行封裝,那麼咱們在使用的時候就會變得很是方便。
值得注意的是:使用視圖專一於邏輯,但不提升查詢效率
臨時表和視圖的區別
存在方式:
臨時存在於 服務器內存中
視圖 無存在形式
生命週期:
臨時表 Sql服務關閉就消失
視圖 你不刪它就不會消失
用途
臨時表 常常做爲 中間轉接層
視圖 做爲物理表的窗口
效率
臨時表由於在緩存中,因此執行效率比較高{不知道大數據量時如何??}
視圖 通常吧?若是是嵌套了別的視圖效率但是最低了{但願高手再說說}
在存儲過程使用時:
臨時表,效率很高{多是數據量少,再加上臨時表是在緩存中,因此執行效率高}
視圖 好象通常(據說2005中有索引視圖,但據說它缺點很多?
三個範式是什麼
首先要明確的是:知足着第三範式,那麼就必定知足第二範式、知足着第二範式就必定知足第一範式
第一範式:字段是最小的的單元不可再分
- 學生信息組成學生信息表,有年齡、性別、學號等信息組成。這些字段都不可再分,因此它是知足第一範式的
第二範式:知足第一範式,表中的字段必須徹底依賴於所有主鍵而非部分主鍵。
- 其餘字段組成的這行記錄和主鍵表示的是同一個東西,而主鍵是惟一的,它們只須要依賴於主鍵,也就成了惟一的
- 學號爲1024的同窗,姓名爲Java3y,年齡是22歲。姓名和年齡字段都依賴着學號主鍵。
第三範式:知足第二範式,非主鍵外的全部字段必須互不依賴
- 就是數據只在一個地方存儲,不重複出如今多張表中,能夠認爲就是消除傳遞依賴
- 好比,咱們大學分了不少系(中文系、英語系、計算機系……),這個系別管理表信息有如下字段組成:系編號,系主任,系簡介,系架構。那咱們能不能在學生信息表添加系編號,系主任,系簡介,系架構字段呢?不行的,由於這樣就冗餘了,非主鍵外的字段造成了依賴關係(依賴到學生信息表了)!正確的作法是:學生表就只能增長一個系編號字段。
參考連接:
juejin.im/post/5a9ca0…
drop、delete與truncate分別怎麼使用?
不一樣的要求執行