SQL猜想 (轉)

SQL猜想 (轉)[@more@]

  　　　　　　學 習 中 的 思 考
 　　　　　　海風
  學習知識常常讓人陷入無知的恐懼中，過去打破沙堡問到底的精神在這裡要有所節制了，我們把握好一個度的問題，要明確自己到底現在最應該知道的是些什麼；不執著於現在還不是時候該知道的知識，只於心中存在一個問號待以後有意或無意間來解決。疑問是學習的靈丹妙藥，我常常抱著懷疑的精神去思考書本中敘述的知識，亦常常先入為主去推敲未知的知識，但有發現自己的猜測有正確之處便沾沾自喜，如若有誤亦為書中的解決之道歎服與興奮。

MS　 SERVER 心得與猜想：

  是門高深的學問，有些知識雖然不太清楚，但我們可以推測可以思考。我們知道一個資料庫裡有很多個表，一個表裡有很多欄位，一個欄位上定義有很多規則。那讓我們想想，一個記錄裡包含所有欄位對應的值，而記錄的數量是可變的，欄位的個數也是可變的，可變加可變讓我們建立維護管理資料庫帶來了方便，問題是，怎樣實現這樣的功能呢？我們查詢資料修改資料時可以選擇指定的欄位指定的記錄，我們也一樣用得很高興，可是，為什麼這樣子可行呢？在沒有看過資料庫結構有關書籍之前，讓我大膽地猜測：欄位是相對獨立的，他擁有自己的屬性，我們用陣列連結串列把表中的各個欄位連結起來，這樣我們就可以動態地增減欄位數，各個記錄欄位的對應值都應該有指向上一個與下一個對應欄位值的指標，這樣就形成一個十字交叉連結串列，記錄也就可以方便地管理了，我們好像也能自由選擇特定的欄位來顯示與修改了，而且因為有指標這位大俠的幫忙，資料就可以方便地亂放了；可是，還有問題，增減一個欄位好像要修改所有的記錄，我們的SQL語言好像也是面向集合的語言，這樣子的結構可行麼，高效麼？我不知道，我只是隨便想想罷了。還有啊，資料庫裡表與表之間的關係，在儲存結構裡又該如何表述呢？預設與規則又是如何的繫結到欄位呢？唉，算了，到此為止，有空再想。

：儲存過程由一組SQL語句組成，他們共同完成一個任務，我們用一個名字（可能還和一些叫引數的符號組成的一串符號）來表示這組語句；那麼，在訪問資料庫時，我們就可以向資料庫所在的傳送這個名字，那麼伺服器就對應的SQL語句組，並返回結果給客務機，這就達到減少傳送的資料效果。

：觸發器定義了一組SQL語句，當我們對指定的表進行修改時， 就會觸發對應的觸發器，執行特定的SQL語句組，以保證資料的正確性和一致性。

：由索引頁和資料頁組成；索引頁由一個或幾個資料項為關鍵字進行排序而組成，同一個關鍵字可以對應一個以上的記錄，並儲存有指向特定記錄的指標，透過關鍵字的排序可以加快查詢記錄的速度，資料頁是實際的儲存資料的頁面。填充因子的作用是：因為在與的資料中，總是預先或優先把儲存位置相近的資料調入記憶體以減少缺頁中斷；所以在每個索引頁中預先留出一部分空間，使得在新增索引資訊時能夠保持資料的連續性，從而加快查詢速度。

資料庫的：我們要使用SQL Server，需要使用一個登入名來連線SQL伺服器，登入名提供了使用伺服器的權力但並沒有提供使用伺服器中的資料庫的權力；帳號提供了使用資料庫的權力，所以我需要為登入名提供一個使用者賬號以便在登入伺服器的同時能使用其中特定的資料庫；不同的使用者賬號使用資料庫的是不同的，比如有的使用者只能檢視資料而不能修改，有的使用者能夠賦給別的使用者使用資料庫的權力，於是我們使用角色來為擁有不同許可權的使用者分類，把擁有相同許可權的用使用者集中起來管理，我們在建立資料庫使用者的同時也指定了他在資料中扮演的角色（使用資料庫的許可權）。員與資料庫擁有者擁有管理資料庫的最高權力。我們還可以為資料庫使用者指定對資料庫中的表，檢視，，儲存過程所擁有的許可權，以從更低階的資料物件來管理資料庫安全。

  當我們擁有了使用資料庫應有的許可權時，在使用者應用中，我們是怎樣使用資料庫中的資料的呢？我們可以使用語句來建立一個臨時表，應用程式使用者能夠看到的使用的僅限於這個臨時表，這個臨時表擁有指向基表（實際上的有儲存資料的表）對應欄位資料的指標，透過這個指標，我們就可以間接地修改選定的表中記錄記段的資料了。臨時表中的指標指向的，可以是基於特定表中特定欄位中的資料，擁有如此小物件的資料的地址，我們因此可以聯合查詢修改數個表中的資料。檢視，可以理解為用一個字串替換一句SELECT語句，以後要使用特定的SELECT時只需使用這字串替換就行，這樣減輕了我們書寫SELECT語句的負擔，當然也浪費了儲存空間來儲存（存在系統表中）SELECT語句的資訊。因為應用程式使用者是透過指標間接訪問資料的，所以當我們改變資料庫的物理儲存結構時，不必修改使用者程式，只需修改使用者程式中臨時表的資料地址就行了，而地址是動態自動分配的，這樣就保證的使用者程式的穩定性。也許改變物理儲存結構，我們只需重新編譯一下索引就行了，索引頁存有資料的地址，臨時表中的地址可方便地從索引頁中獲取，索引頁不大，獲取地址的很高。

COM的思考；

在C++語言中，類封裝了資料和操作其中資料的方法（函式），當我們需要操作類中的資料時，我們就需要方法函式，要呼叫函式運算元據就要知道函式的程式碼段的地址，在同一程式中，地址可以這樣子表示：類名.函式名。無論你身在何處，只要你有辦法獲取函式的地址，知道函式名的定義，就可以使用函式來運算元據並得到返回結果。於是，當我們有辦法聯接遠端計算機並得到其中可執行程式程式碼中的一個函式地址，我們就可以遠端呼叫（透過傳輸資料）這個函式使之在計算機中執行並將得到返回的結果傳輸回本地計算機上。我們要計算機完成的任務，基本上都是透過呼叫函式來完成的。於是，在我們的程式中，如果我們知道其他可獨立編譯執行程式中的函式的地址，我們就可以呼叫他來為我們的程式服務。於是我們就可以把各個相對獨立的程式聯合起來共同完成我們的任務。COM物件模型就是為了解決這個技術問題而設計出來的。在COM中，我們設計了各種型別的介面來為函式呼叫提供地址，每個介面都擁有自己的函式，也可以有自己私有的資料。各個介面類都有一個派生物件作為COM類的一個成員；於是我們就可透過介面類呼叫（把派生物件地址賦給介面）存在於COM類中的派生物件的成員函式。那麼， COM程式編譯獨立執行，只要能把派生物件地址賦給介面，再在我們需要使用COM中功能的程式中加入介面，呼叫COM中的函式功能也就能實現了。COM實現了真正的物件導向技術，他把函式的實現細節完全隱藏了起來，COM元件中，可以方便地新增一個介面來實現新的程式功能，只需在原來的程式碼加上一個介面程式碼就行了，原來的介面仍然可用。COM元件類的儲存結構是以二進位制形式順序儲存的，因此只要知道一個介面的地址就可以透過地址偏移量計算出COM其它介面的地址，也就可以方便地實現介面之間的切換了。我們透過介面呼叫COM中函式，為了使COM能在不同的語言中使用，專家們設計了標準介面語言IDL，以此為中介，實現用各種語言書寫的有相同功能和引數的介面的轉換；當我們用特定語言編寫COM時，先把其介面定義轉換為IDL介面定義的形式，再透過IDL把介面轉換為其它語言所能識別的介面；這樣就實現了COM程式碼的重用性與語言無關性。

現在我們遇到的最大問題是：如何建立COM例項並獲取其地址供程式使用，如何實現COM程式碼同時被多個程式所共享。這是個令人頭痛的問題，很多地方我都未能理解。為實現COM的共享，我們設計一個所有介面的基類IUnknown介面，IUnknown介面有一個函式QuerInterface來實現介面的切換，一對函式AddRef各Release來增加與減少他的引用計數成員m_dwRef；每當元件返回一個新的介面時，程式就呼叫AddRef來使m_dwRef加一，當結束一個介面的使用時就呼叫Release來使m_dwRef減一，當m_dwRef變為0時就刪除元件物件。因為其它介面都是從IUnknown派生而來的，他們繼承了m_dwRef成員，使這個引用計數能正確記錄下正在使用元件的使用者數，實現了共享元件的管理。在ATL實現方案中，專家們設計了一個智慧指標來封裝完成有關引用計數的功能，有人稱這種功能的實現者為垃圾收集器。在伺服器方面，我們需要做些什麼準備呢？我們需要把CLSID、實現名等信註冊到登錄檔中，以供客戶遠端啟用使用。當客戶需要COM服務時，遠端計算機根據客戶發過來的CLSID在記憶體中檢視對應元件是否已被啟用，如果已被啟用了，即在元件服務程式中尋找到類物件，再呼叫其中的方法建立一個物件，並透過QueryInterFace返回一個介面指標給客戶使用；如果沒被啟用，就需要先在登錄檔中尋找到與CLSID相對應的執行程式地址，在SCM的幫助下裝載伺服器程式，然後再尋找類物件返回介面指標。

為了解除客戶與物件的併發性和重入限制之間的關係的模型，建立物件與程式和執行緒之間相互關係的模型，出現了套間這個概念。一個套間可被多個物件共享，這些物件共享一組併發性和重入限制，套間被設定為物件介面的一個屬性；同一時刻，執行緒要想使用COM中的方法，必需先進入一個套間中，其它沒有進入套間的程式雖然也能得到COM方法的地址，但被禁止呼叫。套間把客戶程式所要使用的COM管理起來，以供客戶執行緒方更安全地呼叫。唉，其實很多知識我現在還不太明白，不想多說，看了一些書本的描述後，反而讓我想起了一些問題。COM是獨立編譯執行的，裡面擁有一些全域性變數和在一些方法中需要訪問臨界資源，如果有多個客戶同時需要使用這些變數會發生一些什麼情況呢？

很多時候，我的一些想法與思考都只能證明我的無知與膚淺，有實際意義的想法並不是很多，可我已習以為慣，別人喜歡笑就讓他笑去吧，反正我現在的確不懂那些知識的，的確很無知。初學COM，有點消化不良，再次把我帶到另一個迷惘，我努力發揮智力推測未知，確發現難以找到著力點，推出的結果連自己也覺得荒唐可笑。雖然現在沒能對COM有個系統的認知，不過仍然相信自己有能力成為COM專家，因為，我喜歡計算機技術，因為我要靠他吃飯。

  2002年7月8日