TMG-L Archives

Archiver > TMG > 2004-07 > 1088751882


From: Paul Blake <>
Subject: RE: Assigning ID Numbers
Date: Fri, 2 Jul 2004 00:04:53 -0700 (PDT)


In message of 1 Jul, "Lee Kaiwen" <> wrote:



> I apologize, because this isn't really a TMG-related question. I looked

> elsewhere, but didn't find a satisfactory solution, so given the incredible

> wealth of genealogical experience in this forum, I thought I'd toss my

> problem out here.

>

> After years of computerized genealogy, I've decided I'm way past due in

> organizing my hard copy stuff. Before I start opening boxes and creating

> endless stacks of folders and other papers, I'm trying to establish a

> flexible filing/organizational system. The first step in that process is

> figuring a system for assigning individual and family group ID numbers. I'm

> reading DeBartolo Carmack's book on organizing your research, but the system

> she describes in the early chapters -- based on ahnentafels -- appears to be

> rather inadequate to the task at hand.

>

> Instead, I've devised an ahnentafel-based system that works something like

> this:

>

> DLA - direct-line ancestor: any individual on your pedigree chart

> DLF - direct-line family group: any family in which BOTH parents are DLAs

> CS - collateral spouse: any spouse of a DLA who is not also a DLA; e.g., a

> stepparent.

> CR - collateral relative: any blood-relation who is not on your pedigree.

>

> DLAs just use their ahnentafels as IDs. DLFs are assigned the head of

> household's ID as the family group ID (e.g., family group #4 is my paternal

> grandfather's family, including my father and his siblings). CSs are

> assigned the ID of the DLA spouse postfixed with a, b, c, etc., indicating

> spousal order (e.g., my stepmother is #2b). And finally, all other CRs are

> given an ID consisting of the family group ID of the DLF from which they're

> descended, followed by a decimal and a number indicating birth order -- one

> dot and number for each generation removed from the DLA.

>

> Some examples:

>

> 2 is my father.

> 2.1 is my sister.

> 2.1a is my brother-in-law.

> 2.1.1 is my niece or nephew.

> 2b is my stepmother.

> 2b.1 is my half-sibling.

> 2b.1.1 is my half-niece or -nephew.

> 4.1.3 is the third child of my paternal

> grandfather's firstborn; i.e., my cousin

> 27b.2.5.3 is my second half-cousin, once removed



Reluctantly, I am going to break away from my usual role as a silent observer and add my two cents to this discussion in the hopes of providing you some guidance. There are a couple of caveats however: naturally, my advice is free, there will likely be conflicting opinions, and finally, you must ultimately decide for yourself the organizing system that best meets your needs.



Generally speaking, many people when facing the task of organizing their hard stuff confront a different type of problem entirely: should I put all birth certificates together, death certificates together, census records together, or should I keep all documents together that pertain to each individual? My personal preference is to file documents according to type, all birth records together, all death records together, etc. However in terms of developing a labeling or numbering system, which is the basis of your question, it really does not matter since the numbering method should be exactly the same in my opinion.



Your message indicated that you are already running into problems in attempting to adopt a numbering scheme. These include the unwieldy length of ID numbers for several lines that go back 30 generations, and the difficult task of assigning IDs based upon a pedigree page number. This last idea is not a very good one in my opinion. Although pedigrees may be published one person per page, it is not possible that by switching printers, typeface, or font size, your page numbers might be thrown off and bring ruin to your system? While this may be a poor example, what about the discovery of a previously unknown child that you must subsequently add? I strongly recommend that you listen to the advice previously provided by Mr. Tim Powys-Lybbe . His reply was rich with possible scenarios that would present challenges to your numbering system and other similar schemes. Finally, his concluding words, Give it a good think first before you throw out the normal prac!
tice of
random reference numbers. There has to be a reason where every system designer does it this way.



As a systems designer, I would like to share with you why it is done this way by explaining one of the golden rules of data architecture: Key fields and identifying item numbers should serve one purpose and one purpose onlythey should point to where a particular piece of data is located, physically and/or logically. They should be dumb numbers, i.e., randomly generated, or sequential numbers; one should never embed intelligence into these key fields, (which is exactly what you are proposing to do with your numbering scheme). Why should they be dumb numbers? The answer is because the computer has far better methods of keeping track of all of this intelligence, methods that are both powerful and quite flexible. You are wasting your effort if you redundantly build this same intelligence into an inflexible numbering scheme and it will only add to your list of problems as time goes on. In the end, it defeats the purpose of even having a DBMS (database management sy!
stem).



I believe I understand what you are attempting to do and how you would like to organize your papers and documents. I cannot fault you at all in this regard. However, my advice to you would be to start opening up those boxes of documents and simply start numbering them sequentially as you remove them from the box. Then file them away according to these sequential numbers. Let the machine keep track of how the data is organized and what the relationships are between all of the people. After all, that is what a DBMS does best, and it is one of the main purposes it even existsto relieve you of all of this thinking, planning, record keeping, and tedium.



Tims response included some excellent examples of some anticipated dangers if you continue down your current path. I would like to provide one more. Since the machine is keeping track of the data relationships and data dependencies, etc., it simply needs a number to point to where any particular document can be found. With your numbering scheme, granted, you will be providing such a number and location. However, you will also be introducing an additional problem that you should not normally need to worry about: data synchronization. The need for this will occur when the data relationships (people and families) being maintained by the computer conflicts with the built-in intelligence about those same relationships in your numbering scheme. You will create a tremendous amount of unnecessary work for yourself making corrections to your numbering scheme, not to mention re-filing, to keep everything in sync. Furthermore, when you need to make an inquiry, will you let the!
computer
do its job, or will you rely upon your file numbering system to find your answer? The simple fact remains: where you file a particular piece of paper does not matter. What is important is that you can find it reliably.



My last argument concerns the superior job the computer will do for you in generating the ahnentafels you described as the basis of your system. The computer will also do something for you that your numbering scheme can never do. Right now, your system is based upon YOUR direct-line ancestors and family groups. Please consider that with a few simple keystrokes, the computer can provide many alternate views of this same data, including other ahnentafels, for example, the direct-line ancestors and family groups of your step-mother's third cousin four times removed. You probably do not anticipate a need for such, but you never know. Once again, where a particular piece of supporting data is physically stored or how it is numbered does not matter when you look at the big picture. What is important is that you can reliably find what you need when necessary.



Before the age of computers, a system such as the one you are proposing was necessary to bring order to ones papers and to define and label the many individual relationships in ones family history. To do it now with such powerful technology at our fingertips is similar to reinventing the wheel. It is most unnecessary. Allow your computer to do what it was designed to do for you. In my opinion, you will waste many hours developing and implementing your filing system, while instead you could easily just start numbering everything sequentially and filing it accordingly. When a particular question arises that requires that original documents be consulted, the computer can always tell you exactly where to go and what documents to pull. I would even wager that pulling the documents filed this way is no less fast than if those documents had been filed using a complex numbering system.



I apologize for being long-winded, but considering how rarely I speak up, I ask that you please indulge me this one time. These are my personal opinions based upon my professional training and experience. I also recognize some people may find that having supporting documents labeled and filed so that they closely correspond to their ancestry chart has unusual appeal. I commend these people for their painstaking diligence, but it is not for meI have better things to do with my time. I am content to label and file things in what would seem to be helter-skelter order because I know that I can rely upon my computer to easily and quickly bring order to what would seem to be chaos. I encourage you to have faith that your computer can do the same for you.


This thread: