add document debating guid-vs-book closing issues

git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@9683 57a11ea4-9604-0410-9ed3-97b8803252fd

src/doc/guid.txt

@@ -0,0 +1,52 @@
+
+                 GUID's - Globally Unique Identifiers
+                           Design Issues 
+                           -------------
+
+                   Linas Vepstas November 2003
+
+Summary:
+--------
+GUID's are meant to uniquely identify a GnuCash object. However,
+when that object is backed up (by copying a gnucash data file),
+the identified object is no longer unique.  Book closing is a
+formalized means of saving older data.  If a GnuCash data set
+is large, and SQL is the storage backend, then making copies
+of old data can be very wasteful of storage space.  However,
+book closing, by definition, must retain a copy of the data 
+'as it once was', as an (auditable) historical record.  This
+document debates different alternate schemes resolving the 
+uniqueness, searchability, copies and storage-space issues 
+that come up when handling GUID's on book closing.
+
+
+Introduction:
+-------------
+GUID's are meant to be a way of identifying a given GnuCash entity.
+Accounts, transactions, splits, prices and lots all have GUID's.
+GUID's can be used as a reference: by knowing a GUID, the matching
+entity can be found.  Because GUID's are 128 bits long, one could 
+have a billion different GnuCash users in a million different solar
+systems without worrying about accidentally assigning the same 
+GUID to two different objects.  So, given a GUID, one should be able
+to come up with the object uniquely identified by it, right?
+
+One practical problem is that backup copies of files containing
+GnuCash data will have the same GUID's as the 'live data'.  Because
+the user may have modified the object, if one looked at the backup 
+copy, one would find more-or-less the same object, but it might
+have different values (for the amount, the value, teh date, the 
+title, etc.)  Thus, a single value for a GUID can be associated
+with several different but similar 'objects'.
+
+A related practical problem occurs with the 'closing of books',
+which is a certain formalized way of making a kind of backup.
+After one has accumulated a lot of financial data, one has to 
+periodically make a permanent record of that data, and then
+weed through it to throw away old (no longer interesting) 
+transactions.  The 'closed book' contains all of the old 
+transactions, while the 'open book' looks just like it (has the 
+same accounts, etc), but doesn't have the old transactions.
+
+
+