本文詳細描述了 note IDs，并且解釋了 Domino or Notes 任務 (復制等)使用 note ID 的組件時有什么不同以及 API 程序怎么使用他們. note ID 包括如下部分:
UNID (Universal Note ID) - 唯一地確定了文檔(note), 不管它(note)是位于何處或所處何時.另一方面, 每個文檔(note)的復本擁有相同的 UNID, 并且 UNID 不會因為文檔的更改而變化.
OID (Originator ID) - 確定文檔(note)的特殊的修訂版本,不管它(note)位于何處，也就是說榨馁，每個文檔(note)的復本擁有相同的 OID, 但是當文檔(note)更改時OID也會隨之修改.
GNID (Global Note ID) - 確定一個特殊數據庫中的一個特殊文檔(note)米者，GNID 不會隨文檔(note)的改變而變化揩悄。一個文檔(note)復本的GNID可能會不同颂斜，因為畢竟他們在數據庫中的位置可能不同为迈。
NID (Note ID) - 確定給定數據庫中的一個特殊的文檔(note)壁公。NID 不包含數據庫的信息(只在數據庫內定位有效：譯者注)感论，并且文檔(note)修改時不會變化。
IID (Instance ID) - 確定一個給定數據庫中的一個文檔(note)的特殊修訂版本紊册，IID 不包含數據庫信息比肄，文檔(note)修改時，IID會變化囊陡。
GIID (Global Instance ID) - 確定一個特殊數據庫中的一個文檔(note)的特殊修訂版本. GIID 包含數據庫信息芳绩。The GIID 文檔(note)修改時，IID會變化撞反。
你可以從 Notes 用戶界面可以檢查 ID 的信息妥色。在視圖中選擇一個文檔并且打開它。然后選擇菜單 文件 - 文檔屬性遏片。Notes 顯示“文檔屬性”信息框嘹害。在信息頁撮竿，Notes 顯示和這個文檔相關聯的數據信息，包括文檔創(chuàng)建和修改的日期和時間以及note ID 信息笔呀。 note ID 信息顯示成三行幢踏，包含關鍵字和16進制字符。
對于一個典型的文檔许师，通常是這個樣子：
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
這三行包含所選文檔 Originator ID (OID), Universal Note ID (UNID), Global Note ID (GID), 和 Note ID (NID) 房蝉。
The Universal Note ID (UNID) and the Originator ID (OID)
第一、二行組成了完整的 Originator ID微渠， Originator ID 由 Universal Note ID (整個第一行)加上序列時間和序列號(第二行)：
Originator ID (OID) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
Universal Note ID (UNID) =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
Sequence Time =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
Sequence Number =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
Originator ID (或 Universal Note ID)的前兩部分由文件號(File member)和文檔號(note member)組成搭幻。第一行由 "OF" ("Originator ID - File")，緊跟16個16進制字符逞盆，然后是連字符 "-" 檀蹋，然后是 "ON" ("Originator ID - Note")，后面又是16個16進制字符云芦。 "OF" 后面連字符之前的16個16進制字符構成了OID的文件號(File member)续扔。"ON" 后面連字符之前的16個16進制字符構成了OID的文檔號(note member)。
OID.File =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
OID.Note =
ID: OF0000039D:3836C29F-ON85255DC9:0056FB94
SD00255DF4:0057B8FA-SN00000003
DB85255CD9:00567287-NT0000C092
在頭文件 nsfdata.h 中包含了下面的定義 ORIGINATORID 數據結構和 UNIVERSALNOTEID 數據結構：
typedef struct {
DBID File; /* Unique (random) number */
/* (Even though this field is called "File," */
/* it doesn't have anything to do with the file!) */
TIMEDATE Note; /* Original Note Creation time/date */
/* (THE ABOVE 2 FIELDS MUST BE FIRST - UNID */
/* COPIED FROM HERE ASSUMED AT OFFSET 0) */
DWORD Sequence; /* LOW ORDER: sequence number, 1 for first version */
/* HIGH ORDER WORD: flags, as above */
TIMEDATE SequenceTime;/* time/date when sequence number was bumped */
} ORIGINATORID;
#define OID ORIGINATORID
typedef struct {
DBID File; /* Unique (random) number */
/* (Even though this field is called "File," */
/* it doesn't have anything to do with the file!) */
TIMEDATE Note; /* Original Note Creation time/date */
} UNIVERSALNOTEID;
#define UNID UNIVERSALNOTEID
文檔的 Originator ID (OID) 確定了同一個文檔(note)的所有復本焕数。OID 由兩部分組成：Universal Note ID (UNID) 和序列號(sequence number)纱昧、序列時間( sequence time)。 UNID 唯一的確定了同一個文檔(note)的所有場合的復本堡赔。序列號(sequence number )和序列時間( sequence time) 放在一起區(qū)別同一文檔(note)的不同版本识脆。
Universal note ID (UNID) 確定了駐留在所有服務器上的同一個文檔(note)。然而善已，UNID 缺少直接訪問一個給定數據庫中的文檔(note)的信息灼捂。UNID 用于從一個文檔來(note)引用另一個指定的文檔(note)。答復文檔中的"$REF" (FIELD_LINK) 域包含了其父文檔的 UNID 换团， DocLinks(參見nsfdata.h中的 NOTELINK 數據結構)包含了鏈接文檔(note)的 UNID 悉稠，和鏈接視圖的 UNID 以及鏈接文檔所在數據庫的 ID (ViewLinks 包含了相同的信息，不同的是鏈接文檔的那部分全部設為0艘包， 而 DatabaseLinks 包含的信息是鏈接文檔和鏈接視圖的部分全部設為0) 的猛。UNID 的重要特征是它能總是確定同一個文檔()，不論它是否更新過想虎。
UNID, the OID, 和復制器( Replicator)
Universal Note ID (Originator ID的第一部分) 唯一的確定了同一文檔(note)的所有版本和復本卦尊。如果兩個文檔(note)具有相同的UNID則它們互為復本。因此舌厨，相同文檔(note)的所有復本的不同版本都有相同的 UNID岂却。這就導出一個必然的結論：一個數據庫中不能含有兩個具有相同UNID的文檔(note)。如果復制器(replicator)發(fā)現同一個數據庫中兩個文檔(note)具有相同的UNID，它就會產生一個錯誤消息寫到日志里躏哩，并且不對文檔進行復制署浩。
完整的 Originator ID, 從另一個方面唯一地確定了一個文檔(note)的一個特殊版本。就是說扫尺，一個文檔的相同版本的復本具有相同的OID瑰抵。同時，一個文檔(note)復本修改后器联，它就會有不同的OID。因為在文檔(note)被編輯后婿崭， Domino 和 Notes 會增加序列號(sequence number)和序列時間(sequence)拨拓。 當文檔(note)的一個復本保持不變，而另一個復本被編輯并修改氓栈，于是這兩個復本具有相同的 UNID但是序列號(sequence number)和序列時間(sequence times)不同渣磷，因此OID也不同。
Domino 復制器(replicator)使用UNID 來匹配數據庫中的文檔(note)授瘦，例如：如果數據庫A和數據庫B進行復制醋界，數據庫A中有個文檔含有特殊的UNID，但是數據庫B中沒有提完，于是復制器(replicator)在數據庫B中創(chuàng)建一個該文檔的復本拷貝形纺。
如果數據庫A中包含一個文檔(note)同時數據庫B中有個文檔(note)和它有相同的UNID，復制器(replicator)推斷這兩個文檔 (note)是同一個文檔的兩個復本徒欣。這種情況下逐样，復制器(replicator)繼續(xù)檢查兩個文檔的序列號(sequence number )和序列時間(sequence time)，然后復制器(replicator)推斷是否是同一時間更新過需不需要復制打肝。如果序列號(sequence number )或序列時間(sequence time)其中有一個或兩個都不同脂新，復制器必須決定哪一個是最近更新的哪一個比較舊一點。
如果其中一個更新過粗梭，而另一個未更新過争便，這樣第一個復本的序列號會比第二個復本的序列號大，復制器(replicator)根據這種情況使用第一個復本覆蓋第二個復本断医，從而達到兩個數據庫同步的目的滞乙。
復制沖突
復制沖突(Replication conflicts)發(fā)生在同時編輯并保存同 一個文檔(note)。如果用戶修改了數據庫A中的一個文檔復本鉴嗤，而另一個數據庫B中的文檔復本也被修改(所作修改都在上一次成功復制之后酷宵，下一次復制之 前)，于是兩個文檔復本具有相同的序列號()但是序列時間不同躬窜。這種情況下浇垦，復制器產生一個復制沖突，因為一個文檔的兩個復本在同一時期都進行了修 改荣挨。(如果把一個文檔的多個復本看成是同一個文檔的話男韧，這就表示同一個文檔同時被修改朴摊。)
復制器通過生成復制沖突文檔處理這種復制沖突。序列時間較早的文檔(document)被標志為沖突文檔此虑。兩個數據庫中將會具有兩個文檔甚纲，只不過序列時間較早的文檔會成為序列時間較晚的文檔的答復文檔。
復制器產生復制文檔沖突朦前，會在沖突文檔前標志黑色菱形標記介杆。復制器把序列時間較晚的文檔拷貝到序列時間較早的文檔所在的數據庫中，并完整的保持它的 OID韭寸。 然后復制器把序列時間較早的文檔轉成一個新的文檔生成一個截然不同的 OID 并給它增加一個特殊的條目 "$Conflict" (VIEW_CONFLICT_ITEM) 春哨。 這個 $Conflict 條目會使文檔在視圖的左邊顯示一個黑色的菱形標記，表示它是一個沖突文檔恩伺。 復制器也會給這個沖突文檔增加一個$REF 條目使他變成答復文檔赴背，$REF 條目中含有其父文檔(序列時間較晚)的UNID。
