悟透delphi 第十一章 面向物件資料庫基礎
阿新 • • 發佈：2019-02-11
第二節 資料物件的標識
我們在關係資料庫的設計和開發中，可能經常需要一些唯一的編號或標識，用來作為關鍵字，以區別每一個不同的人，每一張不同的單據，每一次不同的資訊登記，等等。並且，我們也一直採用這些編號和標識，作為關係的連線欄位。但是，要保證編號或標識是完全唯一的，卻是一個不大不小的難題。
下面我們將詳細討論這一問題，並希望能從另一個高度來理解這一問題。不過，我們首先來看看問題是怎樣由來的。現在，給大家講一個故事。
從前，在北京降生了一個漂亮的小女孩。接生的李阿姨說，她的聲音這麼大，好象想要全世界的人都聽到。
他的父母就為她取了一個很好聽的名字，叫“王菲”。於是，所有的小朋友就叫她“王菲”，“王菲”就是她童年的標識。
在她上初二的時候，認識了二班另一個叫“王菲”的同學，而且和她同一天生日。不過，同學們常常將她倆叫錯，後來，就分別叫她們“大王菲”和“小王菲”。
在大王菲18歲的那一年，她領到了她的身份證。從此，她有了新的身份標識“100321690808022”，這一標識可以唯一區別中國大陸的每一個人。同時，原來二班的“小王菲”也領到了她自己的身份證，“100321690808006”。於是，人們就可以用身份證號，唯一標識兩個“王菲”了，雖然誰也不會直接叫她們的身份證號碼。
由於她的歌唱的非常好，沒多就就成了歌星。歌迷們將“王菲”這一標識與她的歌緊緊地聯絡在一起。
後來她去了香港發展，並將自己的名稱更改為“王靖雯”，同時還領到了香港的身份證，有了香港的身份標識。
沒多久，王靖雯和一個彈電吉他的小子相愛了。那小子說，還是“王菲”這個名字好聽。後來，“王靖雯”又變回“王菲”了。結果，歌迷們又遇到了麻煩，是將她的歌關聯到“王菲”還是“王靖雯”呢，在歌迷中引起一陣混亂。
她和那個彈電吉他的小子結婚了，香港政府將他們的身份證號碼，用結婚證書關聯起來。可是，月老在酒醒之後發現了這一錯誤，就將關聯的記錄刪除了。
雖然，她和那個彈電吉他的小子分手了，但是，正如接生的李阿姨說的那樣，她的聲音的確讓全世界的人都聽到了。
講完這個故事之後，你應該能領悟到設計資料庫的一些哲理。
不管王菲的外部屬性和內部屬性怎樣變化，但王菲還是王菲，不是二班的那個“王菲”。也就是說，王菲的靈魂未變，她是不會改變的，就象哲學上所說的“不以人的意志為轉移”。這種唯一表示物件本身的東西，就是物件標識！
物件標識是唯一的。也就是說，即使兩個物件，他們的外部屬性完全一樣，但它們的物件標識是不同的。畢竟，同名同姓甚至同一天出生的大王菲和小王菲是兩個不同的人。
物件的標識是永恆不變的。一旦物件產生，它的標識就自然地、唯一地產生了。儘管王菲換了名，身份證號也變過，但王菲的物件標識未變。即使到了下個世紀，她的物件標識也將依然存在於歌迷們的們的心中。
物件的標識是描述關係的基礎。王菲唱的歌是王菲唱的，不是初二二班的那個“王菲”唱的。王靖雯唱的歌就是王菲唱的歌，有的歌迷只將歌曲和歌手的人名關聯起來，難怪會出混亂。香港政府也犯相同的錯誤，將王菲的身份證號碼這一內部屬性，跟那個彈電吉他的小子關聯起來，也許就是命運的錯誤。
在關係資料庫中，表的每一元組（記錄）描述了物件的各個屬性。也需要人為地選擇某些物件屬性欄位作為關鍵字，以標識不同的資料物件。
關係資料庫的理論說，一個表中，所有列的值都相同的行，也就是欄位都相同的兩條記錄，描述的是同一資料物件。為了區分屬性相同，但物件不同的大王菲和小王菲，就需要引入關鍵字的概念。於是，大王菲和小王菲都才有了身份證號碼。
關係資料庫的理論，強行將物件的屬性定義為關鍵字，以區別不同的物件，這才給我們留下了“插入異常”、“修改異常”和“刪除異常”，等等，讓我們頭痛多年的問題。正是因為這一原因，初二的同學才會混淆“王菲”和二班的“王菲”，歌迷們才會搞不清“王靖雯”和“王菲”的關係，這些錯誤在現實中也是存在的。
其實，物件的標識應該是和物件屬性不同的東西，物件的標識才是資料物件的唯一關鍵字，不以人的意志為轉移的。象人的姓名和身份證號是否應該唯一，以及單據編號是否連續等等，是由人們的規則確定的，與人們的意識有關。
那麼，到底應該用什麼東西來作物件標識呢？
如果，你的資料庫只是臨時管理初二二班的作業本，用學生姓名作物件標識又未尚不可。如果，你的資料庫管理的是中國大陸的戶口檔案，肯定可以用身份證號碼作物件標識，不過，身份證號升位之後，你又要辛苦了。
如果，你的資料庫要管理整個宇宙的資訊，那麼，就只能自己產生標識了！
為資料產生唯一的物件標識，一直都沒有一個公認的好方法。不過，我們可以作一些有益的探討。目前，大致有兩種方法用於產生物件標識：
一． 增量產生
這種方法就是每次產生物件標識時，到資料庫裡查詢一下最大的物件標識。新的物件標識將在當前最大物件標識基礎上增量生成，然後，新的物件標識又成為資料庫中的最大物件標識。
這中方法可以保證在一個數據庫內可以為每一物件生成唯一標識，並且儲存物件標識所用的位元組數很少（例如，一個整數）。這種物件標識，在資料庫內查詢和索引都有較高的效率。
但是，由於這種方法在每次產生物件標識時，需要訪問資料庫。特別是在多使用者使用時，還要採用資料庫的事務機制來防止不同使用者產生相同標識。因此，產生物件標識的效率很低，特別是在批量產生時。
此外，由於這種方式生成的標識只能保證在某一資料庫內是唯一的，不能直接適用於多資料庫或分散式資料庫環境下。在不同的資料庫之間傳遞或同步相同的資料物件時，需要解決物件標識的轉換問題。
二． 隨機生成
隨機生成物件標識的方法實際就是碰運氣，按照某種複雜的隨機演算法迅速產生物件標識，碰一碰物件標識不重複的運氣。只要這種演算法產生的物件標識一萬年才可能重複一次，那你就可以在實際開發中應用這種演算法。
這種方法典型的應用就是COM物件的GUID。雖然，在理論上總有一天會產生重複的GUID標識，但我們等不到那一天，也許那是地球毀滅之後的事情。
首先，這種方法產生物件標識，不需要訪問資料庫，是在資料庫環境之外生成物件標識。因此，標識的生成是一瞬間的事，效率非常高，即使是在批量生成的情況下。
其次，由於在多資料庫或分散式資料庫環境中的不同地方，也不會產生相同的物件標識，因此，在資料庫之間傳遞或同步資料時將不存在物件標識轉換的問題。LOTUS NOTES中的文件管理資料庫，就大量採用這一技術。
由於，為了保證有足夠的數值空間，供隨機演算法產生唯一標識，需要用較多的位元組存放這一物件標識，將耗費較多的儲存空間。GUID是一個長達128位，即16個位元組的資料型別，而NOTES的文件標識也是相當長的資料型別。並且，對較大的資料型別進行索引或查詢，會花費較大的時間和空間開銷，不過，這一問題不向想象的那樣嚴重。
在面向物件的資料庫理論中，每一資料都抽象為一個物件，而且，每一物件都應該有一個唯一的物件標識，並且在物件誕生之後永遠不便。物件的標識是唯一的關鍵字，物件的屬性是否唯一，是商業邏輯所決定的。物件之間的關係，是通過物件標識的關聯來描述的，任何物件屬性的改變不會影響物件標識所連線的關係。
…………….
第二節 一個實用的物件標識方案
隨機產生物件標識。在實際的資料庫程式設計中，
1． 要有足夠的隨機空間
2． 要有較高的執行效率
3． 便於閱讀理解和查詢
INT64許多資料庫不支援。
使用double的好處，空間大，有硬體支援運算。
1.00000000000001E-309到9.99999999999999E307
有效位數從1.00000000000000到9.99999999999999
以格林威治時間為物件標識的生成基準，可保證全世界的物件標識生成時間有統一性。使用GetSystemTime函式，與GetLocalTime函式是不一樣的。
第三節 面向物件的未來
迷信面向物件技術的程式設計師相信，世界上的一切東西都可以用類來描述，用物件來建模。誠然，自從有了面向物件的思想之後，原來複雜的資料結構、軟體演算法變得那麼的清晰和簡單。面向物件的思想改變了我們對軟體的看法。就像當初結構化程式設計思想將人們的思維從錯綜複雜的演算法中解救出來一樣，面向物件的思想讓我們的思維聚焦在高層次的軟體體系設計方面，而不再困惑於軟體基本的資料和演算法方面。因為，軟體基本的資料和演算法都封裝成為物件而已，而且現在這些物件就象建築材料一樣到處都能找到，有磚，有瓦，有鋼精水泥製成的大梁……。在軟體產業的飛速發展和不斷締造輝煌的今天，面向物件思想功不可莫。記得大陸開始改革開放時，第一件事就是“解放思想”。由此可見，新的思想在人類進步歷程中起著重要的作用。
然而，任何一種思想都有侷限性，或者需要不斷的發展和完善。從客觀上講，現行的面向物件程式設計技術已經相當成熟，面向物件的資料庫也在發展。但在實際應用開發中，總能碰到難以解決的問題，總能萌發出無法實現的偉大構想。
任何一種技術都不是萬能的，追求完美將永遠是一種痛苦。
我們在關係資料庫的設計和開發中，可能經常需要一些唯一的編號或標識，用來作為關鍵字，以區別每一個不同的人，每一張不同的單據，每一次不同的資訊登記，等等。並且，我們也一直採用這些編號和標識，作為關係的連線欄位。但是，要保證編號或標識是完全唯一的，卻是一個不大不小的難題。
下面我們將詳細討論這一問題，並希望能從另一個高度來理解這一問題。不過，我們首先來看看問題是怎樣由來的。現在，給大家講一個故事。
從前，在北京降生了一個漂亮的小女孩。接生的李阿姨說，她的聲音這麼大，好象想要全世界的人都聽到。
他的父母就為她取了一個很好聽的名字，叫“王菲”。於是，所有的小朋友就叫她“王菲”，“王菲”就是她童年的標識。
在她上初二的時候，認識了二班另一個叫“王菲”的同學，而且和她同一天生日。不過，同學們常常將她倆叫錯，後來，就分別叫她們“大王菲”和“小王菲”。
在大王菲18歲的那一年，她領到了她的身份證。從此，她有了新的身份標識“100321690808022”，這一標識可以唯一區別中國大陸的每一個人。同時，原來二班的“小王菲”也領到了她自己的身份證，“100321690808006”。於是，人們就可以用身份證號，唯一標識兩個“王菲”了，雖然誰也不會直接叫她們的身份證號碼。
由於她的歌唱的非常好，沒多就就成了歌星。歌迷們將“王菲”這一標識與她的歌緊緊地聯絡在一起。
後來她去了香港發展，並將自己的名稱更改為“王靖雯”，同時還領到了香港的身份證，有了香港的身份標識。
沒多久，王靖雯和一個彈電吉他的小子相愛了。那小子說，還是“王菲”這個名字好聽。後來，“王靖雯”又變回“王菲”了。結果，歌迷們又遇到了麻煩，是將她的歌關聯到“王菲”還是“王靖雯”呢，在歌迷中引起一陣混亂。
她和那個彈電吉他的小子結婚了，香港政府將他們的身份證號碼，用結婚證書關聯起來。可是，月老在酒醒之後發現了這一錯誤，就將關聯的記錄刪除了。
雖然，她和那個彈電吉他的小子分手了，但是，正如接生的李阿姨說的那樣，她的聲音的確讓全世界的人都聽到了。
講完這個故事之後，你應該能領悟到設計資料庫的一些哲理。
不管王菲的外部屬性和內部屬性怎樣變化，但王菲還是王菲，不是二班的那個“王菲”。也就是說，王菲的靈魂未變，她是不會改變的，就象哲學上所說的“不以人的意志為轉移”。這種唯一表示物件本身的東西，就是物件標識！
物件標識是唯一的。也就是說，即使兩個物件，他們的外部屬性完全一樣，但它們的物件標識是不同的。畢竟，同名同姓甚至同一天出生的大王菲和小王菲是兩個不同的人。
物件的標識是永恆不變的。一旦物件產生，它的標識就自然地、唯一地產生了。儘管王菲換了名，身份證號也變過，但王菲的物件標識未變。即使到了下個世紀，她的物件標識也將依然存在於歌迷們的們的心中。
物件的標識是描述關係的基礎。王菲唱的歌是王菲唱的，不是初二二班的那個“王菲”唱的。王靖雯唱的歌就是王菲唱的歌，有的歌迷只將歌曲和歌手的人名關聯起來，難怪會出混亂。香港政府也犯相同的錯誤，將王菲的身份證號碼這一內部屬性，跟那個彈電吉他的小子關聯起來，也許就是命運的錯誤。
在關係資料庫中，表的每一元組（記錄）描述了物件的各個屬性。也需要人為地選擇某些物件屬性欄位作為關鍵字，以標識不同的資料物件。
關係資料庫的理論說，一個表中，所有列的值都相同的行，也就是欄位都相同的兩條記錄，描述的是同一資料物件。為了區分屬性相同，但物件不同的大王菲和小王菲，就需要引入關鍵字的概念。於是，大王菲和小王菲都才有了身份證號碼。
關係資料庫的理論，強行將物件的屬性定義為關鍵字，以區別不同的物件，這才給我們留下了“插入異常”、“修改異常”和“刪除異常”，等等，讓我們頭痛多年的問題。正是因為這一原因，初二的同學才會混淆“王菲”和二班的“王菲”，歌迷們才會搞不清“王靖雯”和“王菲”的關係，這些錯誤在現實中也是存在的。
其實，物件的標識應該是和物件屬性不同的東西，物件的標識才是資料物件的唯一關鍵字，不以人的意志為轉移的。象人的姓名和身份證號是否應該唯一，以及單據編號是否連續等等，是由人們的規則確定的，與人們的意識有關。
那麼，到底應該用什麼東西來作物件標識呢？
如果，你的資料庫只是臨時管理初二二班的作業本，用學生姓名作物件標識又未尚不可。如果，你的資料庫管理的是中國大陸的戶口檔案，肯定可以用身份證號碼作物件標識，不過，身份證號升位之後，你又要辛苦了。
如果，你的資料庫要管理整個宇宙的資訊，那麼，就只能自己產生標識了！
為資料產生唯一的物件標識，一直都沒有一個公認的好方法。不過，我們可以作一些有益的探討。目前，大致有兩種方法用於產生物件標識：
一． 增量產生
這種方法就是每次產生物件標識時，到資料庫裡查詢一下最大的物件標識。新的物件標識將在當前最大物件標識基礎上增量生成，然後，新的物件標識又成為資料庫中的最大物件標識。
這中方法可以保證在一個數據庫內可以為每一物件生成唯一標識，並且儲存物件標識所用的位元組數很少（例如，一個整數）。這種物件標識，在資料庫內查詢和索引都有較高的效率。
但是，由於這種方法在每次產生物件標識時，需要訪問資料庫。特別是在多使用者使用時，還要採用資料庫的事務機制來防止不同使用者產生相同標識。因此，產生物件標識的效率很低，特別是在批量產生時。
此外，由於這種方式生成的標識只能保證在某一資料庫內是唯一的，不能直接適用於多資料庫或分散式資料庫環境下。在不同的資料庫之間傳遞或同步相同的資料物件時，需要解決物件標識的轉換問題。
二． 隨機生成
隨機生成物件標識的方法實際就是碰運氣，按照某種複雜的隨機演算法迅速產生物件標識，碰一碰物件標識不重複的運氣。只要這種演算法產生的物件標識一萬年才可能重複一次，那你就可以在實際開發中應用這種演算法。
這種方法典型的應用就是COM物件的GUID。雖然，在理論上總有一天會產生重複的GUID標識，但我們等不到那一天，也許那是地球毀滅之後的事情。
首先，這種方法產生物件標識，不需要訪問資料庫，是在資料庫環境之外生成物件標識。因此，標識的生成是一瞬間的事，效率非常高，即使是在批量生成的情況下。
其次，由於在多資料庫或分散式資料庫環境中的不同地方，也不會產生相同的物件標識，因此，在資料庫之間傳遞或同步資料時將不存在物件標識轉換的問題。LOTUS NOTES中的文件管理資料庫，就大量採用這一技術。
由於，為了保證有足夠的數值空間，供隨機演算法產生唯一標識，需要用較多的位元組存放這一物件標識，將耗費較多的儲存空間。GUID是一個長達128位，即16個位元組的資料型別，而NOTES的文件標識也是相當長的資料型別。並且，對較大的資料型別進行索引或查詢，會花費較大的時間和空間開銷，不過，這一問題不向想象的那樣嚴重。
在面向物件的資料庫理論中，每一資料都抽象為一個物件，而且，每一物件都應該有一個唯一的物件標識，並且在物件誕生之後永遠不便。物件的標識是唯一的關鍵字，物件的屬性是否唯一，是商業邏輯所決定的。物件之間的關係，是通過物件標識的關聯來描述的，任何物件屬性的改變不會影響物件標識所連線的關係。
…………….
第二節 一個實用的物件標識方案
隨機產生物件標識。在實際的資料庫程式設計中，
1． 要有足夠的隨機空間
2． 要有較高的執行效率
3． 便於閱讀理解和查詢
INT64許多資料庫不支援。
使用double的好處，空間大，有硬體支援運算。
1.00000000000001E-309到9.99999999999999E307
有效位數從1.00000000000000到9.99999999999999
以格林威治時間為物件標識的生成基準，可保證全世界的物件標識生成時間有統一性。使用GetSystemTime函式，與GetLocalTime函式是不一樣的。
第三節 面向物件的未來
迷信面向物件技術的程式設計師相信，世界上的一切東西都可以用類來描述，用物件來建模。誠然，自從有了面向物件的思想之後，原來複雜的資料結構、軟體演算法變得那麼的清晰和簡單。面向物件的思想改變了我們對軟體的看法。就像當初結構化程式設計思想將人們的思維從錯綜複雜的演算法中解救出來一樣，面向物件的思想讓我們的思維聚焦在高層次的軟體體系設計方面，而不再困惑於軟體基本的資料和演算法方面。因為，軟體基本的資料和演算法都封裝成為物件而已，而且現在這些物件就象建築材料一樣到處都能找到，有磚，有瓦，有鋼精水泥製成的大梁……。在軟體產業的飛速發展和不斷締造輝煌的今天，面向物件思想功不可莫。記得大陸開始改革開放時，第一件事就是“解放思想”。由此可見，新的思想在人類進步歷程中起著重要的作用。
然而，任何一種思想都有侷限性，或者需要不斷的發展和完善。從客觀上講，現行的面向物件程式設計技術已經相當成熟，面向物件的資料庫也在發展。但在實際應用開發中，總能碰到難以解決的問題，總能萌發出無法實現的偉大構想。
任何一種技術都不是萬能的，追求完美將永遠是一種痛苦。